If you haven’t read James Rotering’s, “Thoughts on developing a template strategy… and my new template click-through utility” I would definitely recommend it. It presents what I consider a novel approach to MODx template strategies. It never would have occurred to me to manage templates using his technique.
After commenting (yes, I am quoting myself here which is odd) I began to think that it might be beneficial to jot down a few points on how I have been approaching my own template strategy:
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… 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.
Organizing HTML
When I build a site I begin by creating a single page of standards compliant HTML. This tends to be my core template. I usually refer to this as my “structural” HTML as opposed to my “contextual” HTML which may vary based on my template. My intent is to have “structural” HTML surrounding variable, “contextual” areas of the page. Once created, I find I rarely have to touch my “structural” HTML again.
I then use my CSS document(s) and the HTML of the “contextual” areas to create layout variations. It’s also possible to create a dynamic CSS document to help with this, as well as using an inherited Template Variable (TV) calling varying CSS documents into the HTML head.
I agree with James, code repetition should be absolutely minimized. I have simply taken a different path to this conclusion.
Chunks
I rarely place my “structural” HTML directly into the Templates. What I do is to break the area above the content into a {{header}} chunk and the area below into a {{footer}} one. Most of my templates then look like:
{{header}}[*content*]{{footer}}
This allows me to reuse the same code base across all templates while assigning TVs to specific templates. I can then insert logic above or below the content areas. This insertion can occur within the template or within the header and footer chunks themselves.
By placing code outside of the chunks I have been finding that I create a greater number of templates, but if this is undesirable it may be offset because the concept of a template is easily understood (even by a novice developer). Any given template choice equates to a single layout or set of behaviors. Even though it is being driven from a single, shared code base. Over time I have come to believe that this may allow for easier long-term management.
When inserting code inside of the chunks I will typically use single, serial PHx statements to create the logic for these areas or sometimes I will rely on nested PHx statements, depending on my requirements. This PHx logic is often based on document ID, template ID or if the document is a folder. Over the past year or two this approach has been preferable to me, particularly when needing a child document to inherit the template from a parent. This provides variable layout/behaviors from within a given template. While this can be very functional I am not sure of how easily others will interpret my code down the line when using this approach.
Other Strategies
I realize that my techniques may not work for everyone. To date I have not developed projects with large numbers of templates. Usually less than 10. I would assume that my strategies would becomes harder to manage as this number increases. Which may be a significant advantage with an approach like James’s.
One of my favorite aspects of MODx is that there are so many possibilities for using very different techniques to address any single set of issues. Personally, I would love to see more posts/comments about other MODx template strategies and am really looking forward to the Advanced Templating topic at the upcoming MODxpo in Dallas.
