Thoughts on developing a template strategy… and my new template click-through utility

I’m keeping the sarcasm and clever wit to a minimum today, and putting out a request for comments.

One of the things I’ve done in the process of working with MODx over the past few months is to create a rather elaborate and convoluted template schema.  Initially I was trying to keep everything to one single, swiss-army-knife template.  That’s where the idea to use  a Template Variable to select a content layout came from.

That seemed promising, but as I went further down the road of One-Template-To-Rule-Them-All, I realized I was trying to wring some not-very-straightforward functionality out of MODx.   Things like “I need some Template Variables to be conditional upon other Template Variables”.  As in,  its great to be able to select “three column layout” in a TV, but unless I have additional TVs for “left column content” and “right column content”, I can’t do much with those additional columns.  But it doesn’t make sense to have “left column” and “right column” TVs on pages that don’t have those columns. Et cetera. I had begun to weave an overly-complicated web of confusion that was quickly collapsing upon me.

Thankfully the good folks on the MODx core team finally smacked some sense in to me in a response to a forum post.  At this point I realized that the “one template” concept was a non-starter.

However.

I was still enamored with the overall concept that I think can best be described as “template inheritance”.  I knew that most of my templates would share 90% of their DNA, and only differ from each other slightly – a div here, an additional css file there.  I knew I wanted to keep code repetition to a minimum, and keep the templates themselves very clean and very rarely-needing-to-be-touched.

What I finally settled on was a highly nested chunk structure, with lots of placeholders for custom bits.  One big breakthrough was when I realized that you can pass arguments to a chunk that can then be used as placeholders within a nested chunk.  In other words:

[[$outerchunk? &customdiv=`foo` &customclass=`bar`]]

‘outerchunk’ looks like this:

<div>
<p>some text…</p>
[[$innerchunk]] <!–note how innerchunk doesn’t directly pass any arguments –>
</div>

…and ‘innerchunk’ looks like this:

<div class=”[[+customclass]]“>[[+customdiv]]</div>

And the result looks like this:

<div>
<p>some text…</p>
<div class=”bar”>foo</div>
</div>

Now my template structure really started tightening up. I had arrived at something like this:

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”&gt;
<html xmlns=”http://www.w3.org/1999/xhtml”&gt;
<head>
<title>[[*pagetitle]]</title>
[[$metaBlock]]
[[$cssBlock? &customCssChunk=`...`]]
[[$scriptsBlock? &customScriptsChunk=`...`]]
</head>
<body>
[[$header? &customTopDesignChunk=`...` &customHeaderChunk=`...`]]
[[$content? &navigationChunk=`...` &contentLayout=`...`]]
[[$footer? &customFooterChunk=`...`]]
</body>
</html>

…which I then consolidated even further to look like this:

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”&gt;
<html xmlns=”http://www.w3.org/1999/xhtml”&gt;
<head>
[[$head? &customCssChunk=`...`
&customScriptsChunk=``
]]
</head>
<body>
[[$body? &customTopDesignChunk=`wwwTopDesignBlock`
&customHeaderChunk=`wwwHeader`
&navigationChunk=`wwwNavigation`
&contentLayout=`25_50_25`
&customFooterChunk=`wwwFooter`
]]
</body>
</html>

I’m currently debating whether to take the final step and just put the entire html structure into a single chunk:

[[$tplHTML &customCssChunk=`...`
&customScriptsChunk=`...`
&customTopDesignChunk=`wwwTopDesignBlock`
&customHeaderChunk=`wwwHeader`
&navigationChunk=`wwwNavigation`
&contentLayout=`25_50_25`
&customFooterChunk=`wwwFooter`
]]

I’m hesitant just because for some reason it comforts me to see a little bit of recognizable html in my templates… but really, this is probably the logical conclusion of the path I’ve gone down.  Code repetition is absolutely minimized; inheritance and extensibility are optimized.  Fully centralized control of the “common template family DNA”, and extremely customizable end pages, through a combination of custom chunks (as seen above) and template variables (for adding bits of css, jQuery, etc. on a per-page basis).  What could be better?

The downside?  An extremely convoluted chunk hierarchy that quickly makes my head hurt.

It started driving me nuts trying to visually parse these nested chunks, to see what bits of the final html source code where in which chunk.   I started to yearn for a quick way to grok my chunk nestings.

In the absence of any such utility, and at my wits’ end, finally I was driven out of my inherent laziness and compelled to develop one.

Behind that link is my rough first draft of a template click-through utility.  Currently it only expands chunks.  In the future I plan to enhance it to expand snippets, placeholders, etc.   But first I thought I’d solicit some feedback.  Is this something that anyone besides me would find useful?   As David Letterman would say, “is this anything?

Take a look, and let me know what you think.  I’d appreciate any feedback whatsoever, either on the template viewer utility or on my convoluted template strategy.  If there is enough interest, I may do a future post on how the utility works, and also possibly release some incarnation of it as an add-on package.

About these ads

16 responses to this post.

  1. Okay. First,. I like the chunk viewer.

    Second.

    I understand minimizing code repetition. I do.

    But there’s such a thing as the law of diminishing returns. I kind of like simplicity, that is me. I’m okay with having several files, because I’m not what Julia Childs would call a pot saver.

    In a kitchen? when you’re cooking, if you’re concerned about the pots then you tend to not do as well with the food. I think there is something to be said for this type of template strategy if it makes things more usable, makes life easier for people, or makes the site run better. Then it is a matter of measuring how much. Sort of rating the ROI.

    For me, trying to document the process for others to understand and be able to work with might make it not worth it. I’d rather have 6 templates and be able to come back to it a year later without a manual than build out something like that.

    but then, my sites are different, different environment. Only you know if this is worth it.

    really interesting concepts though. Seriously.

    Reply

    • Some great thoughts. One small bit of self-awareness I am in possession of is the fact that I am a repeat offender in regards to breaking the law of diminishing returns. I’m desperately trying to learn the right balance between ruthless efficiency and taking things too far.

      I think this is the right strategy for me because the management of these templates (and there will be more; lots more) will fall almost entirely on me, with perhaps one or two others as backups. My end users will just be selecting and using them, not looking at or caring how they are built… so in that regard it doesn’t matter if they aren’t immediately intuitive at first glance. I think that, as far as being able to maintain a few dozen mostly-identical-but-each-slightly-unique templates, without having to touch each one when I need to make a change to the overall structure, this is the right way to go.

      BTW love the pots analogy; I’m one who somehow manages to dirty more pots and pans than the number of dishes I’m making. One of my favorite things about ‘Julie and Julia’ was how they’d show her whip up these amazing meals, then pan over to the sink where approximately 1,351 dirty dishes were piled up. I know in my house, whoever does the cooking, the other one does the dishes…

      Reply

  2. Posted by Chris ONeal on April 12, 2010 at 8:35 pm

    Funny, I feel like we’re on the same path to enlightenment. You are just one step ahead of me so you may have saved me some headache. I think, if packaged, your little utility could come in very handy, if not for the end-user, more for me when I go back to the site 12 sites later… nice job.

    Reply

    • Glad to know I’m not the only one forging my way down this path, Chris. Thanks for the feedback. I do hope to get the utility fleshed out a bit more and packaged in some sort of useful way.

      Reply

  3. This is really interesting work. Thanks for sharing.

    I find myself going up and down these roads too. How do you squeeze the most out of MODx without over-complicating things? I am like you in that I believe that I am the primary user when I build a site, but I am finding out over time that that is less and less true. The longer we go (my business) and the more customers that come on board I am beginning to see that there are more people coming behind me in my code. Which was not the case when the code was written.

    My approach is beginning to be shaped by the assumption that others will need to function in my code later down the road. Lately that leaves me searching for solutions that not only make sense to me, but that will make as much sense to them without a dissertation from myself.

    I was very excited by your post, I spend almost all day every day inside of MODx and I sill had to read your post a couple of times to wrap my head around it. While I appreciate the efficiency and novelty of your solution(s) I am not sure how well it lends itself to being interpreted down the line.

    Reply

    • Thanks for the feedback Greg.

      I understand fully where you are coming from. One of the things that sold me the most on MODx initially was the inherent simplicity of the templates: straight html with intuitive placeholders for the content. And now I’ve clearly strayed from that simplicity.

      On the other hand, I think this whole road I’ve gone down has made me somewhat rethink my old definitions of simplicity. Granted I have lost the ability for a future colleague/successor to look at my templates and immediately say “I see precisely how this works”. They might instead need to spend an hour or two familiarizing themselves with the chunk syntax (although the click-through utility should greatly aid that process). But once they “get it”, they will then be looking at a collection of templates that has (due to the chunk strategy) remained perfectly in sync over the years, through numerous changes to the underlying html structure. Whatever change they need to make, whether it effects one template, a subset, or the entire group of templates, they will be able to make in one place. To me, that is a more sustainable type of simplicity than the alternative (very straightforward html templates that run the risk of getting horribly out-of-sync with each other after a few years’ worth of incremental changes).

      This is definitely a solution that is geared toward keeping a large collection of templates in sync. It is overkill for sites that have only a handful of templates. For sites like that, the simple truth of “MODx templates are just HTML!” need not be tampered with.

      Reply

  4. [...] you haven’t read James Rotering’s, “Thoughts on developing a template strategy… and my new template cli… I would definitely recommend it. It presents what I consider a novel approach to MODx template [...]

    Reply

  5. [...] About « Thoughts on developing a template strategy… and my new template click-through utility [...]

    Reply

  6. Great article again. Definitely a situation where a site with dozens of templates would benefit from this technique (and I’d honestly vote for the uber-chunk style). Half a dozen or less, I’d probably stick with more traditional approach per Anne’s comments above.

    Reply

    • Thanks for the feedback, can’t tell you how validating and encouraging that is. I could see this topic being a chapter in a future MODx book… assessing your site’s needs and choosing a template strategy on the spectrum from straight HTML to the “Single Chunk Technique”. I think both ends of the spectrum, and the fact that there is a range of possible templating approaches at all, are all major selling points for MODx.

      Reply

  7. [...] more: Thoughts on developing a template strategy… and my new template … Share and [...]

    Reply

  8. Posted by dave m on July 22, 2010 at 12:50 pm

    Nicely done, James. I do like the hierarchal chunk solution youve come up with.

    Couple of thoughts as I am at the exact spot you are– trying to divy up chunks into a cohesive series of groupings of templates.

    1. The viewer is an excellent idea. One thing that might make it easier for all involved is to some way to visually represent– as in fully mocked html (lorem ipsum…), or in a jpg pic of ‘fully mocked html chunk’ — for each chunk and it’s spot in the heirarchy, in a side column. or bottom column, etc..

    That is to say, when a user clicks on a subchunk, say of ‘navigationChunk’, off to the right they see an image of your actual navbar filled in with mock ‘lorem ipsum’ type text.

    i.e —> Lorum | Ipsem | Dolor | Sit | Amet | Consectetur

    I think that might help to visualize what the chunk looks like filled in– especially if you had all the chunks open in your viewer, and a whole page of a mock filled template appeared.

    Probably kinda complected to build such a device, but ultimately makes the end users life a cinch. (and anyone who takes over for you as admin at anytime) In a perfect world it might have a button below it that flipped between ‘code view’ (raw mocked html) and the ‘site view’ (a mocked browser view with jpgs)

    2. In terms of having one master and physically viewable template design to rule them all:

    What if you used dreamweaver’s style of page markup (or invent your own) to chop one base template up into all the chunks available within it. Call it the ‘master template’ for that group. :

    <!-- #BeginWwwFullPageChunk  chunkId=1 modxTag="[[$1]]"  masterTmpltLoc="{base_dir}/assets/WwwTemplateGroupMaster.xml--> 
    <html>
      <!--#BeginWwwHeaderChunk  modxTag="[[$3]]" -->
       <head>
          
           <title>Lorem Ipsem</title>
    
            <!-- #BeginWwwCustomCssChunk   modxTag="[[$5]]" -->
            <link rel="stylesheet" href="style/Lorem/Ipsum/dolor.css" type="text/css" />
            <!-- #EndWwwCustomCssChunk   -->   
         
       </head>
       <!-- #EndWwwHeaderChunk  -->
    
       <!-- #BeginWwwBodyChunk    modxTag="[[*content]] " -->
        <body>Lorem ipsum dolor amet.</body>
       <!-- #EndWwwBodyChunk  -->
    
    </html>
    <!-- #EndWwwFullPageChunk -->
    

    Not very completed, or showing all your ‘www’ chunks, but you get the gist of having one master template as a visual. ( and im sure the whitespace/tabbing will be munged as I submit)….

    ….Keep the master template onsite somewhere, as Metadata for your template groups. Or ewhen you need to visually see it all together.

    I’d think with another custom attribute or two for each markup/comment node, you might even be able to write a short php script to parse the single master template (xhtml) into all it’s individual chunks automagically. And while youre parsing them, you could even use modx api to insert or update the chunk values right from that grahical master w/o hand entering them.

    That way you could edit and retain the master in sync with the chunks in the modx. (you’d probably have to write the “reverse script” too though — that would use the api to autoupdate the master template on any chunk’s ‘onchanged’ event for completeness.

    Reply

  9. Posted by timewilltell on February 2, 2011 at 5:20 pm

    Funny that people are saying you’re ahead of them, let me save you all a bunch of trouble. Don’t do this. It’s a horrible strategy and adds processing where it isn’t necessary.

    Your templates SHOULD be redundant, I’m going to skip the part where I recount 15 years of development experience and its many paths and simply say this: Your templates should be as static as possible, except for the parts that are actually dynamic.

    The lessons learned even investigating this strategy aren’t even worth repeating, they’re like the lessons learned building sites with HTML tables for a decade. Just forget it, build clean semantic sites and keep your templates so you can open them up in a browser and the only thing your browser can’t do is parse the variables.

    Good luck everyone.

    Reply

  10. I personally blog likewise and I’m authoring something very close to this specific
    blog, “Thoughts on developing a template strategy and my new template
    click-through utility | The CMS less traveled”.
    Do you mind in the event that I actuallymake use
    of a number of of your suggestions? Thanks a lot -Candace

    Reply

  11. What seriously motivated you to write “Thoughts on developing a template strategy and my new
    template click-through utility | The CMS less traveled”?
    I reallyreally enjoyed it! Thanks a lot ,Damian

    Reply

  12. I actually desire to save this specific blog, “Thoughts
    on developing a template strategy and my new template click-through utility | The CMS less traveled” on my personal website.
    Do you care in case Ido it? Thank you ,Margo

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 30 other followers

%d bloggers like this: