Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Conditionals, else, and nesting - best practice
tl;dr: is it better to have have multiple conditionals run in series, or nest them instead?
Consider this code – a bunch of sequential conditionals:
<txp:if_foo>
foo
<txp:else />
not foo
</txp:if_foo>
<txp:if_bar>
bar
<txp:else />
not bar
</txp:if_bar>
<txp:if_baz>
baz
<txp:else />
not baz
</txp:if_baz>
<txp:if_foofoo>
foofoo
<txp:else />
not foofoo
</txp:if_foofoo>
<txp:if_barbar>
barbar
<txp:else />
not barbar
</txp:if_barbar>
<txp:if_bazbaz>
bazbaz
<txp:else />
not bazbaz
</txp:if_bazbaz>…and then the same code with some judicious nesting:
<txp:if_foo>
foo
<txp:else />
not foo
<txp:if_bar>
bar
<txp:else />
not bar
<txp:if_baz>
baz
<txp:else />
not baz
<txp:if_foofoo>
foofoo
<txp:else />
not foofoo
<txp:if_barbar>
barbar
<txp:else />
not barbar
<txp:if_bazbaz>
bazbaz
<txp:else />
not bazbaz
</txp:if_bazbaz>
</txp:if_barbar>
</txp:if_foofoo>
</txp:if_baz>
</txp:if_bar>
</txp:if_foo>In the tests I’ve done, and admittedly they are limited, the first block of code was processed more quickly (lower/shorter runtime) with a lower query time. It’s also, arguably, more easily read by humans – which makes it, subjectively, better.
I am totally happy constructing tag blocks in either way, but I’m looking for the best way of doing this so the browser can render more quickly. Am I missing something, obvious or otherwise, that would help assist me in choosing the best method to follow – nested or not?
Thanks in advance.
Offline
Re: Conditionals, else, and nesting - best practice
I’m slightly sidestepping your question, but by the time it gets that complex, I generally switch to smd_case (smd_multiple_choice I think it’s called) if the logic allows it.
Getting back to your question, might it depend on the individual case? Taking the nested variant first: if your condition is met within the first couple of ifs, the rest are skipped. With the first code block, the code still has to process all the others. I’m just guessing, though.
TXP Builders – finely-crafted code, design and txp
Offline
Re: Conditionals, else, and nesting - best practice
Hi Pete, I seldom use nested code because i find it harder to edit as most of the times, it creates a horizontal scroll bar in the editor.
My editor of choice is BBEdit and I get little arrows which ‘fold’ the code withing the opening and the closing tag so I can – most of the times – check if any tag is left unclosed.
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: Conditionals, else, and nesting - best practice
As with most things, the official answer is “it depends”.
There’s a few things to weigh up and balance against the needs of the site. Primarily:
- Complexity of template (visually), horizontal scrollbar / wrapping / etc.
- Execution path.
- Speed of parser.
- Resource usage.
As colak says, heavily nested structures can get ugly (depends on the number of spaces you use :-) and difficult to read.
But they do mean that your code exits quicker because it doesn’t have to check successive conditionals further down the page. It hits the match, does its stuff and drops out. A caveat to this is that the order of execution makes a difference and, generally speaking, you want your most frequently accessed code paths at the top.
For this reason, I have been known to turn the default page template on its head and check for individual article first, then list page, then category landing page inside that, and author/search last. But if it’s a search-heavy site, I set it to be tested first.
This does mean you may need a mix-and-match nesting system. If the <txp:if_individual_article> comes first then, by inference everything else must be a list. So if we were to check the remaining items in this order (i.e. not nested):
- if_article_list
- if_category
- if_author
- if_search
Then one of the last three could (potentially) get executed in addition to the vanilla article list, doubling up results on the page. So in this instance, a level of nesting inside the if_individual_article’s else block is necessary.
Finally, there’s the speed and resource usage — often two sides of the same coin. The (current) parser itself has to do some heavy lifting when searching for nested <txp:else> tags and keep a stack of previous levels, which accounts for the higher resource usage Pete noted. This can be mitigated somewhat by rejigging the order in which your stuff is nested so most frequent code paths come first (as mentioned above), or flattening the structure in some places where things are mutually exclusive to help the parser out a bit.
If visual maintainability is of primary concern, you can also split thing out into separate <txp:output_form> blocks, which helps to reduce visual clutter and “reset” the nesting level to the left-hand edge at the expense of having to jump between pages to administer it (though adi has a superb plugin to help with this). Each call to a form does potentially incur a DB call though, so that needs weighing up too.
In summary, there’s no right answer. It’s a balancing act based on intended site usage, visual aesthetics / workflow and execution speed. The latter can of course be improved with APC :-)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Conditionals, else, and nesting - best practice
jakob wrote #287817:
Getting back to your question, might it depend on the individual case? Taking the nested variant first: if your condition is met within the first couple of *if*s, the rest are skipped. With the first code block, the code still has to process all the others. I’m just guessing, though.
It may depend on the individual case, yes; that’s possible. I am unsure whether a one-size-fits-all approach is right, or whether – as you say – a case-by-case approach is best.
Offline
Re: Conditionals, else, and nesting - best practice
colak wrote #287820:
My editor of choice is BBEdit and I get little arrows which ‘fold’ the code withing the opening and the closing tag so I can – most of the times – check if any tag is left unclosed.
I use Coda, which behaves most of the time. It’s not completely foolproof, sadly, so the occasional misplaced or unclosed tag can still throw an error.
Offline
Re: Conditionals, else, and nesting - best practice
Bloke wrote #287821:
As with most things, the official answer is “it depends”.
[…]
In summary, there’s no right answer. It’s a balancing act based on intended site usage, visual aesthetics / workflow and execution speed. The latter can of course be improved with APC :-)
I had a feeling it might be a tricksy question to ask, and carry an appropriate answer. Thanks, as always Stef, Yiannis and Julian – I am grateful for your replies.
Offline
Re: Conditionals, else, and nesting - best practice
gaekwad wrote #287815:
Consider this code – a bunch of sequential conditionals:
…and then the same code with some judicious nesting:
It’s not the same code. You get different results. The only time the result is the same is when everything except the last conditional evaluates to false.
In the tests I’ve done, and admittedly they are limited, the first block of code was processed more quickly
In the current parser that is true. The main reason is because the deeper you get in the nesting levels, the more often that code is parsed. The if_bazbaz construct is parsed 6 (!) times before it can be executed; once for each level of nesting. The proposed parser improvements would mostly remove the difference in parsing time.
Offline
Re: Conditionals, else, and nesting - best practice
ruud wrote #287830:
It’s not the same code. You get different results. The only time the result is the same is when everything except the last conditional evaluates to false.
You are absolutely right; I mis-pasted when I was building the code clump for this post.
In the current parser that is true. The main reason is because the deeper you get in the nesting levels, the more often that code is parsed. The if_bazbaz construct is parsed 6 (!) times before it can be executed; once for each level of nesting. The proposed parser improvements would mostly remove the difference in parsing time.
Great info – thanks, Ruud.
Offline