Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: The direction of Textpattern 5
Just want to weigh in on “pages” & “forms” being merged into “templates”.
While I’m not afraid of drastic changes to the core of TXP, I think we need to really focus on a cost/benefit ratio when considering these changes.
An excellent trade off
I’m happy about categories getting all busted up to hell because they desperately need to be refactored in order for TXP to grow.
- Sometimes I need to create duplicate categories for all content types
- Being limited to 2 categories per article is a huge roadblock in building sophisticated sites.
- Custom url schemes get totally fubared by categories with duplicate names
So I’ll gladly recode sites/plugins to get better category handling. I’ll “pay the cost to be the boss” of categories without heistation.
A questionable trade off
In contrast, the idea of merging “forms” and “pages” into “templates” doesn’t seem to have a functional effect beyond some people’s semantic preference. Granted, I think “forms” is a confusing and misleading term given it’s ambiguity in relation to <form>. Calling it “snippets” would be far more accurate. But beyond that, where is the function? How does it make building sites easier? And to acheive this dubious improvement, the effect on plugins would be dramatic. On a personal level it would create a huge workload/expense for me to rebuild plugins and sites.
Thoughts?
Offline
Re: The direction of Textpattern 5
mrdale wrote:
Just want to weigh in on “pages” & “forms” being merged into “templates”.
mrdale – can you refresh me as to where in the thread this is proposed? I’ve been following it since it began, and can’t remember that idea, or find it . . . I’m sure I’m just overlooking it :-) .
I think “forms” is a confusing and misleading term given it’s ambiguity in relation to
<form>. Calling it “snippets” would be far more accurate.
Agreed that “forms” could be more accurately named. Snippets seem to be popular in the software world, and because it doesn’t have the “form” ambiguity, is an improvement. Though I think for the lay person it’s not a word they can automatically relate to either. Perhaps pieces, parts, chunks, ingredients, or some other like term would offer even greater clarity and easy conceptual transfer.
Last edited by maverick (2011-03-02 17:52:35)
Offline
Re: The direction of Textpattern 5
Perhaps pieces, parts, chunks, ingredients, or some other like term would offer even greater clarity and easy conceptual transfer.
Well, I refer to them as bricks like in ‘LEGO bricks’. But ‘form’ is totally OK for me.
I am fine with ‘pages’. My alternative would be ‘markup’ which also fits pretty well to the XTML style of TXP tags. ‘Template’ is so 90s aka web 1.0.
Get all online mentions of Textpattern via OPML subscription: TXP Info Sources: Textpattern RSS feeds as dynamic OPML
Offline
#100 2011-03-02 19:39:12
Re: The direction of Textpattern 5
mrdale wrote:
Just want to weigh in on “pages” & “forms” being merged into “templates”.
maverick wrote:
mrdale – can you refresh me as to where in the thread this is proposed? I’ve been following it since it began, and can’t remember that idea, or find it . . . I’m sure I’m just overlooking it :-) .
First post mentioning merging is post #13 where Ruud put it as a wishlist.
Last edited by Manfre (2011-03-02 19:41:12)
Offline
#101 2011-03-02 20:14:11
Re: The direction of Textpattern 5
Offline
#102 2011-03-02 20:55:43
Re: The direction of Textpattern 5
ruud wrote:
Wishlist:
- Combine “forms” and “pages” into “templates”. There’s really no reason to separate the two (or differentiate between various types of forms) and calling it a “template” is less confusing.
artagesw wrote:
This is the approach Escher takes.
Actually, separate pages and “snippets” is the method I always prefer. For instance, from one of my Movable Type Index Templates:
<div id="content"><div class="col-one">
<$MTInclude module="2008-entry content"$>
</div></div>and what does 2008-entry content Included Module consist of?
<div id="entry-<$MTEntryID$>">
<h2><$MTEntryTitle$></h2>
<p class="entryinfo">
Posted by <$MTEntryAuthorLink show_hcard="1"$>
</p>
<$MTEntryBody$>
<p class="entrymeta">
<span class="date"><$MTEntryDate format="%x"$></span>
</p>
</div>I like keeping the page templates as brief as possible so I can see at a glance what the page is doing. Even the new WordPress templates like TwentyTen have simplified the code down:
<div id="container">
<div id="content" role="main">
<?php
/* Run the loop to output the posts.
* If you want to overload this in a child theme then include a file
* called loop-index.php and that will be used instead.
*/
get_template_part( 'loop', 'index' );
?>
</div><!-- #content -->
</div><!-- #container -->I probably need to go read more, but I would be very sad if that feature goes away.
Last edited by michaelkpate (2011-03-02 21:05:28)
Offline
#103 2011-03-02 21:44:13
Re: The direction of Textpattern 5
ruud wrote:
Wishlist:
- Combine “forms” and “pages” into “templates”. There’s really no reason to separate the two (or differentiate between various types of forms) and calling it a “template” is less confusing.
maniqui wrote:
I like ruud’s suggestion on “merging” both Pages and Forms under the same tab … although I would keep some kind of categorization.
Combining “forms” and “pages” without keeping some categorization could break this section-to-page-template paradigm, and users could make the mistake of trying to do section-to-any-chunk-of-txp-code, which, in current TXP4 paradigm won’t work (unless the “form” contains the full code for a template).
So is the idea proposed primarily a “UI concept” – e.g. to unify the form tab and the page tab into a generic “templates” tab? Then any “template” would be able to call another template (like a page is able to call a form)?
Or is it a more fundamental shift away from having chunks of reusable code?
I guess I’m not sure what Ruud means. I’m being a bit dense I suppose ;)
artagesw wrote:
This is the approach Escher takes.
Now that I went back and read this, I realize I’m not entirely sure what Sam means since Escher has Themes, Templates, and Snippets. Perhaps I’m mistaken, but Templates and Snippets in Escher seems to be the equivalent of Page Templates and Forms in Txp. . . .???
Offline
#104 2011-03-02 22:40:23
Re: The direction of Textpattern 5
- technically and functionally there is little or no difference between the two, so why carry around extra code to support something that can be simplified without losing functionality.
- forms and pages are really nothing but a hard-coded categorization of templates. Combine it on one tab and allow user-defined categorization (unlike the pre-defined form types). One way to do user-defined categorization of templates is to allow templates to have parents and children, so you can organize them in a tree structure (similar to how it works on the category tab).
- I really can’t express how much I dislike the words “forms” and “pages” in this context. Very confusing. I’d prefer “templates”, which does not confuse.
Offline
#105 2011-03-02 23:05:23
Re: The direction of Textpattern 5
ruud wrote:
My wish to combine “forms” and “pages” into “templates” is mainly because:
- technically and functionally there is little or no difference between the two, so why carry around extra code to support something that can be simplified without losing functionality.
Conceptually and organizationally I consider these to fill completely different functions. Page is always top level. And it provides a clear heirarchy for new users. “On this section I use this page”. use forms extensively and don’t want to trade my two tabs for one tab with more items. top level forms (templates) will simply disappear in the cluter.
You could make the argument that “styles” are just “forms” too, now that we’re done with all that base-64 nonsense.
- forms and pages are really nothing but a hard-coded categorization of templates. Combine it on one tab and allow user-defined categorization (unlike the pre-defined form types). One way to do user-defined categorization of templates is to allow templates to have parents and children, so you can organize them in a tree structure (similar to how it works on the category tab).
This is a fine organizational device, but the reality of it is, I often use one form to serve many, many areas of my site on multiple pages, so I’m not sure of the benefit of the herarchial categorization you envision. Please explain.
- I really can’t express how much I dislike the words “forms” and “pages” in this context. Very confusing. I’d prefer “templates”, which does not confuse.
Pages is not confusing, forms are a misnomer, I agree. Frankly I don’t care if I have to search and replace all instances <txp:output_form form="foo" /> with <txp:snippet name="foo"/>
Offline
#106 2011-03-02 23:59:43
Re: The direction of Textpattern 5
mrdale wrote:
Conceptually and organizationally I consider these to fill completely different functions. Page is always top level. And it provides a clear heirarchy for new users. “On this section I use this page”. use forms extensively and don’t want to trade my two tabs for one tab with more items. top level forms (templates) will simply disappear in the cluter.
So it’s mainly about keeping things organized.
You could make the argument that “styles” are just “forms” too, now that we’re done with all that base-64 nonsense.
I’m not. Style sheets are not parsed and have a different MIME-type.
This is a fine organizational device, but the reality of it is, I often use one form to serve many, many areas of my site on multiple pages, so I’m not sure of the benefit of the herarchial categorization you envision. Please explain.
It’s flexible.
You can create a completely flat hierarchy similar to what ‘pages’ does right now.
You can create two parents: pages and forms to mimic the organization enforced by TXP now.
You can create a tree structure that shows how various templates relate to each other.
You can organize it the way you like best. Trees offer that flexibility.
Offline
#107 2011-03-02 23:59:51
Re: The direction of Textpattern 5
Page could just as easily be a form type and still have the benefits described by mrdale.
Piwik Dashboard, Google Analytics Dashboard, Minibar, Article Image Colorpicker, Admin Datepicker, Admin Google Map, Admin Colorpicker
Offline
#108 2011-03-03 00:09:54
Re: The direction of Textpattern 5
ruud wrote:
So it’s mainly about keeping things organized.
yes, and conceptially.
You can create a tree structure that shows how various templates relate to each other.
Got an use case example?
Offline