You're The Nonsense In My Life, You're The Inspiration
I don’t defile a great Chicago ballad for nothing: this templating language really sucks.
When I first saw this while shopping for blog platforms, I said, “Hey, XML tags, that’s hip.” Then I realized that almost the entirety of Textpattern templating involves obtaining the state of the application from the template. Especially whoppers like <txp:if_article_list />. Now it inspires me to do something simpler.
These conditional tags seem noble at first. Whenever a programmer hands off to a designer, any attempt to hand logic in addition to content can kind of be seen as a magnanimous gesture.
But, seriously, who is filling out the forms here? The program kicks logic capabilities out to a flat unexecutable text file, which bounces back questions to the program, which answers them, which in turn results in a submission of a sort of post-processed template to the program again, to put the values back in the blanks.
Why didn’t the program just retain the logic capability? It always knows its own state!
I mean,
<body>
<div id="content">$content</div>
<div id="menu">$menu</div>
</body>
What’s wrong with that? Let the decisions be made upstream. Demand-Pull. Let the themer override rendering patterns (like how an article node is displayed), and provide a fallback so no configuration is technically required. Almost every template engine’s tutorial I’ve seen lead off with “See? You can put your for loop right there in the template so all your articles will render!” No. Or better yet, Why?
Framework-itis, I think. Passing too much control on to the designer.
This is a blog. Stacks of articles with links to individual articles with comments forms. Nothing too tough about it.
I got Framework-itis with Sigma’s combat system during the stall when I didn’t do anything with it. I wanted to hand the designer all the little choices. In the end, the ultimate framework is the programming language that you’re using to write the framework. If you’re not making some decisions for them, they might as well write it themselves.
So, when the program sees that it’s in an article list and needs the $content variable, it asks the theme override (or the default) how to render an article list. The theme replies with a pattern for stacking articles. Then, the program needs to figure out how to render individual articles for the stack, it asks how to do that. The answer comes back.
This is actually the same information as before, but I contend that the average designer will not need to modify many of the things, especially workaday items like how to stack articles. This is even moreso the case when CSS is provided for richly (lots of id and class attributes in th default), which allows skinning via CSS instead of <div> tag monkeying.
Plus, you’re keeping the theme pure by making all the conditional decisions for it. All the theme does is talk back when it’s time to render something.