Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Tag tree best practise: to nest or not to nest
This is perhaps a strange question to ask, but here goes.
I am starting a new site build and I’m questioning my method of stacking tags. Take the following rudimentary example:
<txp:if_article_list>
<txp:if_section name="default">
<txp:if_search>
<p>is search, default</p>
<txp:else />
<p>is article list, default</p>
</txp:if_search>
<txp:else />
<p>is article list, not default</p>
</txp:if_section>
<txp:else />
<txp:if_individual_article>
<p>is individual article</p>
</txp:if_individual_article>
</txp:if_article_list>I’m nesting queries, and they start to stack up pretty quickly. Now, my brain can handle it when I’m building, and if I leave comments on my code I can safely troubleshoot and modify at a later date, but is there such a thing as best practise for not making Textpattern do as much work (whether it’s lower memory usage, fewer queries or something else)?
An alternative is for me to have lots of queries in serial within the page template, removing the else tags and covering each permutation of section, search and article manually. This takes more code, but has a negligible impact on memory usage and query volume.
I’m torn, really. Do I stick to what I know and carefully build nested tags with plenty of else, should I start coding my queries in serial without else, or something different?
Is there such a thing as page and form tag construction best practise?
Offline
Re: Tag tree best practise: to nest or not to nest
As you infer, there’s no right or wrong answer here. It really depends on the complexity of the site. But as a general rule I keep to these basic tenets:
- Two page templates: one for front page, the other for everything else.
- Template code is a very basic HTML structure with dynamic content filled in by Form content (lots of
<txp:output_form />goodness). - All search/category/author/tag landing pages end up on the front page so the complex logic is there and only impacts front page load time. Everything else has a much simpler logic, so cuts down queries / processing and tag soup for the majority of browsing experiences.
- Optimize calls and make use of
<txp:else />wherever possible.
In your case, for example, there’s no need for the individual article test, as you know that the <txp:else /> portion of your <txp:if_article_list> construct must be an individual article.
My ‘everything-other-than-front-page’ template usually ends up looking a bit like this:
<txp:output_form form="head" />
<body id="s-<txp:section />">
<div class="container">
<txp:output_form form="page-head" />
<txp:output_form form="page-nav" />
<div role="main">
<txp:article />
</div>
<div role="complementary">
<txp:output_form form="page-comp" />
</div>
<txp:output_form form="page-foot" />
</div>
</body>
</html>The head form contains calls to sub-forms like head-css, head-meta, head-scripts, etc to keep everything segregated into logical chunks. And the footer encompasses a tail-scripts form for things like bringing in jQuery/piwik and so forth. The forms also follow a sort of naming convention with prefixes so the ones that all start with the same prefix are grouped nicely in the interface (I use the ‘Section’ Form type for things that relate to the page flow or layout, reserving Article types for stuff that puts article-centric content to the page, and Misc for stuff that really doesn’t fit anywhere else!)
I tend not to nest Forms any deeper than that or it gets annoying to find them (though adi_form_links / smd_where_used really help if things have to go further).
Does that give you anything to work on?
Last edited by Bloke (2013-09-24 16:19:52)
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: Tag tree best practise: to nest or not to nest
Stef, this is really useful – I’m on the right track. Thank you very much.
Offline