Article Introduction
This article aims to highlight a approach which allows one to separate everything from one’s business logic to one’s design logic, to XHTML from CSS, one’s Javascript from the page structure, etc., while at the same time being able to be lazy and include, for example, CSS information within the same document (template) as one’s XHTML. The script can also be used for more advanced XML-related features which I won’t go into here. This article assumes some familiarity with Smarty, or at least the concept of templating.
First a quick disclaimer: While the discussion revolves around this open-source Smarty extension class (called SmartyDocB, with documentation), the approach could be applied to templating based on other PHP-specific templating systems, in XSL, etc. However, I don’t have a lot of time now to maintain the code for what I describe below (though I’m happy to try to answer questions if I can), but I feel that the code itself is sufficiently mature, and if nothing else, that its approach to templating is perhaps unique, so in the event that it could be useful for others, I am drawing your attention to it. Perhaps, if there is interest, I may be able to revisit the code at a later date.
I’ll begin with some examples with the templates and give you a quick impression of how this could be used and useful, then go into the specifics of setup, and finally discuss some future goals for the project. I’ll conclude with a discussion of the use of XSL or XQuery for templating and issues of porting one’s templates to use with other programming languages.
Why and How to Use This Templating Approach
An Introduction to The HYSOCAMTT approach “Have-Your-Separation-Of-Concerns-And-Mix-Them-Too”)
I don’t know about you, but when everyone is suggesting external stylesheets over the <style> tag and the W3C deprecated even the @style attribute (which was itself an enabler of the deprecating of previous HTML tags used for formatting), I was unhappy. Not because I didn’t see the wisdom of separating structure from styling—but because it meant I could no longer be lazy—or actually, something which is often equivalent—I couldn’t be as efficient. I’d have to actually open up another file, lose my concentration (my short-term memory is deplorable), duplicate work by finding some means of referencing the structural tag so that the external style information can be applied to it, and then hope that by looking at the structural code in the future without styling cues around it, I’d be able to tell from my class names, to what part of the page the structural code was referring.
For example, while in plain old-style HTML, to make some paragraph small, I could get by with:
<p><small>This website is run by an individual......</small></p>For handling separation of styles, I’d have to:
- Start with: <p>This website is run by an individual……</p>
- Add a class or id (for referencing), so that I didn’t make all of my paragraphs small, and according to good practice, come up with a semantic rather than styling name: <p class=”disclaimer”>This website is run by an individual…</p>
- Then open up and save a new stylesheet file, taking into account a good file location so that moving the file contents wouldn’t break the association, and then add an appropriate <link> (or <?xml-stylesheet…?> if only IE would start supporting it) in the head of my XHTML document to refer back to the stylesheet.
- Add the style declaration, including the full property name (here “font-size”) in question, to the stylesheet: p.disclaimer {font-size: small;}
- Refresh my XHTML to make sure that it works.
And then, in the future, if I looked over my template (or file), I might forget how I styled the disclaimer, and if I wanted to change it, I’d have to open up the stylesheet file if it wasn’t open, and search to find that style declaration. Or, if I were looking at the stylesheet, I might not remember all the files in which I used the disclaimer, so I’d have to open all of my files up to check to see whether any proposed style change in the stylesheet would be suitable everywhere.
Again, there are a whole lot of benefits to separating styles such as greater accessibility, faster downloads, etc., which you can read about in many other articles, but you can see (as you may well know already) how cumbersome the above can be (especially if you’re averse to most IDEs like I am).
Imagine, however, if you could do the following within your template:
{moveto target=css}
p.disclaimer {font-size:small;}
{/moveto}
<p class="disclaimer">This website is run by an individual......</p>And have a script extract the “moveto” contents into a separate site-wide file (site-wide because this speeds up downloads by taking advantage of caching that occurs when the same stylesheet is encountered by a browser on a subsequent visit to the same or another page of the site that includes it). This is exactly what SmartyDocB does. Moreover, it will put comments within the CSS file which indicate from which template the above style originated. So if the above template file was called, footer.tpl, within the site-side CSS file (which could include other auto-generated or manually edited CSS content), the following would be added at the top of the file (to the top to ensure that the developer was aware during testing that subsequent (preexisting) styles weren’t superceding the newly added ones:
/* Begin moveto footer.tpl */
p.disclaimer {font-size:small;}
/* footer.tpl end moveto */
An even more succinct option in SmartyDocB is to use a special syntax to avoid the duplication (of the element and class-name) present above:
<<p eclcss="font-size:small;">>This website is run by an individual......<</p>>What this will do is extract the style information to be added to an external CSS file (removing it from the resulting XHTML structural output), and targeted according to the current element (‘e’) and its class (‘cl’), thus “eclcss”, thereby reproducing the same exact effect as above. Similar attribute exist for targeting to the
February 25, 2008
Tutorials