Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Context, templates, and forms
This is more thinking out loud than a definite feature idea.
Naturally the impending 4.3.0 release has people talking about Txp’s future, and getting excited (or, in some cases, depressed or dismissive). Theming keeps coming up. I’m on the fence about it — I see the main value as maybe attracting a more diverse group of Txp users/designers. But I don’t see how a truly switchable public-side theming system could coexist with what to me is the best part of Txp — its incredibly versatile and powerful system of templates and forms.
That said, there are some oddities to this system. On the abstract theoretical side, Txp’s uneven and sometimes opaque approach to context makes this key concept harder to grasp and leverage than it should be. And on the concrete practical side, the current setup of Txp tags and templates loses its elegance when templates become massive stacks of nested conditional tags, as they tend to do. Well, mine do, anyway.
To be (I hope) clear, I see context as comprising the following:
- section
- article id
- search
- category (which, as of 4.3.0, is subdivided into article and image sub-contexts)
plus other contexts that are purely negative:
- article list (the absence of article id context)
- default section (the absence of explicit section context)
- front page (the absence of article id, search, and category contexts)
and a further complexity in that section is a special sort of context, always present, whereas the other three are mutually incompatible. Section is arguably a purely presentational context but I have never bought that; indeed I think it’s time to drop the idea entirely.
There’s also page number, arguably a sort of sub-context, but I’ll leave it aside.
If you’re still with me I’ll try sidling round to something resembling a point: let’s extend the template/form system to take a more consistent and thorough approach to context. Three areas:
1. Give article more automatic context-based behaviors
In the way that article currently defaults to a form called ‘search_results’ when in search context, extend that behavior to all contexts. In category context, article defaults to an article form called ‘category_list’. In front-page context, article defaults to ‘default_list’. (For backwards compatibility, if the forms don’t exist fall back on ‘default’.) Of course all of this can be overridden by specifying the listform, searchform, or a new categoryform attribute.
2. Make other key tags context-sensitive in the same way
E.g., make category as a single tag default to the ‘default’ form of this type. category_list defaults to ‘default_list’. Additionally, in category context either tag will default to a category form of the same name as the category, if such a form exists (otherwise use the default).
3. User-definable, arbitrary, context-sensitive forms
Getting a bit woolier here. All Allow users to create new form types. Then add a type attribute to output_form. Hence <txp:output_form type="sidebar" /> will choose a form of that type, matching the form name to the context. Possible names: ‘search’, ‘category’, ‘default’, plus any section name. It’s an arbitrary container.
=====
My goal with all of this is to allow for greatly slimmed-down templates. I realize that forms would proliferate, but with the new admin UI enhancements to the Forms tab, it can handle it. I also realize this would involve extra queries and/or storing more data in memory during script execution. But I think this could be done reasonably, by making just one db call after the initial context check, then storing all the default forms for that context. E.g.,
http://foo.com/category/toast
triggers
@SELECT * FROM `txp_form` WHERE `name` LIKE ‘toast’@
SELECT `name`, `Form` FROM `txp_form` WHERE `name` LIKE 'toast' OR type IN ('category')
and those get stashed in the static $forms array.
I have some other vague thoughts about page templates, but I think that’s enough for now :)
Last edited by jsoo (2010-10-05 15:52:21)
Code is topiary
Offline