Is there a good naming convention for *_list forms?

johnstephens · 2011-09-16 17:03:58

Hi!

I’ve seen interesting conversation about form types and naming conventions in The direction of TXP 5 thread, but I was wondering what naming conventions people use for Textpattern 4.

I use cnk_versioning on almost every project, and I’m almost always viewing my templates in Textmate’s file drawer, so the form types add meaning but aren’t useful for sorting. Using rah_output_section_form is what has influenced my naming conventions the most— I use a bunch of misc-type forms called “_content-{section_name}”, and everything else follows a similar pattern. It helps me go into any project I’ve worked on and navigate the templates easily.

What I don’t have a good pattern for are section_list, category_list, and other list forms. I’d love to hear what naming conventions other TXP users have come up with, along with the rationale. Notwithstanding the fact that different projects have different requirements, do you have any patterns that have emerged from continuous use having shown practical value?

johnstephens · 2011-09-16 20:08:57

P.S. If you know of threads where this was discussed before. I searched, and I could only find one thread in which someone gave examples of their naming scheme. Thanks again!

Bloke · 2011-09-21 14:53:49

I’m a bit of a mess in terms of naming as I can never make up my damn mind! And I don’t use cnk_versioning. But my general pattern has evolved into this:

Try and handle article lists in the same Form as individual articles, distinguished using <txp:if_article_list> or <txp:if_individual_article> depending on mood.
Logic for any dedicated lists — searches, category lists — goes in the default page template or landing page where I want to handle that type.
On the occasions where lists demand their own Form I stick to a list_{type} syntax (e.g. list_category, list_products, etc) so they’re all grouped. I’ll normally use ‘article’ Form types for them all.
Any time I find myself writing the same line or very similar tag block twice, I look to farm it out to a dedicated form and use <txp:output_form> + <txp:yield /> to alter params. A handy way of getting multiple values into forms used to be to pass them in pipe delimited and then iterate over the yield with rah_repeat or smd_each. Nowadays I’m more inclined to use an smd_macro though.
Pages are just blocks of div / section wrappers and <txp:output_form> tags with the odd bit of logic thrown in for good measure.
fwiw, I’ve also adopted a standard set of (misc) Forms for headers, footers and other repeated content:
- dtd: great for switching doctypes for a laugh
- head: master <head> block, comprising the <title> + atom tags plus the following sub-forms:
  - head_css: stylesheet logic
  - head_meta: meta tags
  - head_php: site-wide custom code
  - head_scripts: site-wide js like jQuery <script> tags or stuff that must go here
- tail_scripts: remaining js scripts like piwik / facebook API, and page-specific jQuery snippets (selected using <txp:if_section>) that go just before the closing <body>
- page_head: site banner / h1
- page_foot: site footer
- page_nav: main navigation bar

Plus any other page_* blocks as determined by the site (e.g. page_related).

In short, I tend to lump things together with a common prefix based on their location or logical block within the page so I can fold up the other types and work on that ‘bit’ without hefty doses of page scrolling.

I think I’ve been herded to this naming convention because Form names have to be unique across types, when often the site structure benefits a more flexible approach. Now, if we were to allow arbitrary Form types, and keyed the table off the type+name combination I could make a ‘head’ group and call the enclosed Forms css, meta, scripts, … and also have a ‘tail’ group with a Form called scripts as well¹. Or lump all the scripty things together under a ‘scripts’ group. Mwuahahahahaa… ^{stef gets his cloak}

¹ Of course to support this the form="" attributes would have to permit form="type:name" so this’ll probably never happen.

Last edited by Bloke (2011-09-21 14:57:35)

jakob · 2011-09-21 20:06:41

Not sure if this really answers your question but I too switch strategies depending on the site.

For sites that for the most part share an identical layout but that have some sections with different content handling, I’ll use a single page template with all the core items in it together with rah_output_section_form for parts of the page that differ for some of the sections. The forms then look like this:

section_{section-name}
section_{section-name}_js
section_standard
section_standard_js
…

“standard” is the default case (seeing as default is the homepage and invariably differs from the standard page layout) and the forms contain both article list and individual article cases. On sites where some sections require no js at all but several others do, I set rah_output_section_form to default="" and section_standard–js holds the jquery hookup and is nested as the first item of the section-name forms.

For larger sites with varying structure, or when routing url schemes to page templates with gbp_permanent_links, I’ll use several page templates and farm out the bits that repeat across the sections to forms a bit like Stef writes above, except that I name then around the other way around so that item-related forms appear together rather than diverse list types (though that is perfectly valid too):

property_list
property_profile
property_shortlist
property_teaser

If you have a complex site, the list can get long but at least you find what you want. I’ve seen other people develop nifty ways of combining this collection of formlets into a single form and then calling the relevant bit using txp:yield. That shortens the list of forms dramatically.

For all the smaller items, I hardly use forms at all and use txp:article as a container tag.

Textpattern CMS

Textpattern CMS support forum

#1 2011-09-16 17:03:58

Is there a good naming convention for *_list forms?

#2 2011-09-16 20:08:57

Re: Is there a good naming convention for *_list forms?

#3 2011-09-21 14:53:49

Re: Is there a good naming convention for *_list forms?

#4 2011-09-21 20:06:41

Re: Is there a good naming convention for *_list forms?

Board footer