CCSTAL - Caching Client-Side Templating Abstraction Layer
Just what the Internet needs, yet another developer with an idea.
What is CCSTAL?
CCSTAL is anti-technology; I guess the name is sarcastic commentary on the annoying trend to acronym...ize everything. So, it's both a stupid acronym and a word play on "assist all" that describes a technique for abstracting the header and footer of webpage User Interface into an extensible construct that can cache on the client side and be shared by multiple pages within one or more sites. In some very simplified ways it competes with server side techniques to wrap interface around content or WYSIWYG editors from doing something similar prior to upload. You see these done with PHP, Template Toolkit, Wrap, and more on the server, and by Dreamweaver and Frontpage prior to upload. At least in the case of SSI, it's really capable of being more complimentary when a project warrants SSI. It's also an approach to templating and not a language. My examples all use JavaScript (which of course, is a programming language) to create the UI abstractions.
Here's how to do it
- Build your initial page in HTML using CSS
- Break that initial page into logical chunks (specifically a header and footer)
- Convert the HTML for those logical chunks into a string in a JavaScript function
- Build all of your pages content (without those shared chunks), adding remote JS inclusion
Build your initial page in HTML using CSS
Consider a very rudimentary HTML page as an example.
<![CDATA[
<html><head>
<title>My Title</title>
<meta name="keywords" content="my,keywords">
<link rel="stylesheet" href="../style06.css">
</head><body>
<!-- start: main header -->
<table>
<tr>
<td>
Nappy table(s) -- or, for the pure CSS crowd, nested positioned DIV tags (which are just as bad)
The graphics that convey the brand and positioning used to open the page
Possibly the DIV tags for the always-popular-yet-so-often-sadly-misguided drop down menus
And to characterize them appropriately: the supporting lifted-from-someone-else-drop-down-libs
The bread crumbs and other navigational bonanza
And the rest of the header madness that accompanies most if not all "professional" pages.
</td>
</tr>
</table>
<!-- end: main header -->
<!-- start: content -->
Now then, the CONTENT.
The whole reason this page is different than the last one or the next one.
Lots of lengthy, eloquent babble that ultimately will go out of scope before it's time,
it's such a tragedy and all that, etc, etc.
Note: this section often includes call-outs, photos, illustrations, and various chunked
data gimicks designed to "make it easier for the audience to visually absorb the data"
-- but really to feel cool about differentiating himself from those competing for the same eyeballs.
<!-- end: content -->
<!-- start: footer section -->
<table>
<tr>
<td style="background:bottom-section.gif;">
My footer links, the visual elements that close my page, the copyright notice,
contact author info, etc, etc.
</td>
</tr>
</table>
<!-- end: footer section -->
</body></html>
]]>
Break that initial page into logical chunks (specifically a header and footer)
You can see from that example that there's a logical header and footer. Most projects will introduce additional "container types" into the mix. For example, primary navigation (which often can be abstracted with the header construct), secondary navigation such as bread crumbs, or other menu systems, feature boxes, advertisement containers, and more. The rule I use is: if it's going to be used more than once, it's going to be abstracted into it's own construct. If it's not, build it in to the header or footer... if necessary, you can abstract it later. I know that tends to favor the short term, which I gripe about regularly, but irony is the fuel of the universe... or maybe it's hypocrisy, I can never remember which.
Convert the HTML for those logical chunks into a string in a JavaScript function
Create JavaScript functions named header() and footer() (or whatever you prefer... I haven't arrived at the point where the variable naming must following strict guidelines aside from the idea that your naming should convey what the thing is going to do). If this approach begins to experience a wider adoption, it may be advantageous to suggest a common standard for naming components, if only I could be so bold. We'll see if anybody gives a rat's ass.
Here's the JavaScript abstractions continuing from the example.
<![CDATA[
window.header = function(){
var html = ''
+'<link rel="stylesheet" href="../style06.css">'
+'<!-- start: main header -->'
+'<table>'
+' <tr>'
+' <td>'
+' Nappy table(s) -- or, for the pure CSS crowd, nested positioned DIV tags (which are just as bad)'
+' The graphics that convey the brand and positioning used to open the page'
+' Possibly the DIV tags for the always-popular-yet-so-often-sadly-misguided drop down menus'
+' And to characterize them appropriately: the supporting lifted-from-someone-else-drop-down-libs'
+' The bread crumbs and other navigational bonanza'
+' And the rest of the header madness that accompanies most if not all "professional" pages.'
+' </td>'
+' </tr>'
+'</table>'
+'<!-- end: main header -->'
return html
}
window.footer = function(){
var html = ''
+'<!-- start: footer section -->'
+'<table>'
+' <tr>'
+' <td style="background:bottom-section.gif;">'
+' My footer links, the visual elements that close my page, the copyright notice, '
+' contact author info, etc, etc.'
+' </td>'
+' </tr>'
+'</table>'
+'<!-- end: footer section -->'
return html
}
var html = ''
+window.header()
+document.body.innerHTML
+window.footer()
document.body.innerHTML = html
]]>
The string constructs in the script are perhaps a bit ugly, but consider the first time you gazed on HTML. The power of this approach is that once you are done futzing with the header and footer it's pretty much stable, and popping in new pages is super easy. If you are careful how you implement it, then adding new pages is a snap and you get all or most of your navigational functionality for free or at least at low cost. This isn't a lot different than implementing these UI components in a server side scripting language at least in terms of difficulty, but it permits your users to cache the pieces on their machines after loading the first page. Note: There are some WYSIWYG programs that use techniques like libraries and do some global search and replace. I'm not a fan of WYSIWYG for philosophical (and financial) reasons... and my disdain for them extends to templating techniques which are arguably a secondary benefit. Oh how I love to pay Adobe to build my intellectual property for me, and then to permit me to continue using it, and all I need to do is keep paying them for updates, so I never need to learn HTML, FTP, CVS, and JavaScript. At least when the market falls out, I can put on a tie, and "become" a professional tax consultant by Turbo Tax... phew, I never need to actually learn anything but GUI and fine-motor skills, and thanks to XBOX and Windows, I got those in spades! ;-) (Er, ...ok, sorry folks, I'm back on my meds.)
Build your page content and add your JS inclusion to the bottom of each page
Keeping this simple, if we had ten pages of that incredibly useful content, each would replicate the header and footer sections, perhaps with minor variations. Instead, let's break it into a separate library. The example above perhaps becomes something like this...
<![CDATA[
<html><head>
<title>My Title</title>
<meta name="keywords" content="my,keywords">
</head><body>
<!-- start: content -->
Now then, the CONTENT.
The whole reason this page is different than the last one or the next one.
Lots of lengthy, eloquent babble that ultimately will go out of scope before it's time,
it's such a tragedy and all that, etc, etc.
Note: this section often includes call-outs, photos, illustrations, and various chunked
data gimicks designed to "make it easier for the audience to visually absorb the data" but
really to feel cool about differentiating himself from those competing for the same eyeballs.
<!-- end: content -->
<script type="text/javascript" src="template.js"></script>
</body></html>
]]>
Notice the inclusion of the client-side template library script. This is one way it can be done. In this case, the header and footer are abstracted as functions (which means they don't get called until presumably, we're ready). The last part of my example builds a string of HTML from the value returned by the header() and footer() calls, and wraps those around the BODY innerHTML returned from the DOM. The output methodology is similar to those used in many Ajaxian examples in that that string is swapped back into the BODY via innerHTML rather than document.write.
Why would I want to do it
Here are what I believe to be some of the advantages to this technique
- SSI Power, but without the SSI - because you are defining the shared components like you might in a Server Side Include, you get the advantage that you don't have to maintain multiple copies of the same HTML. You also don't have to serve that HTML, so there is a small savings on bandwidth (though typically this is small since it's HTML which of course is very light comparatively speaking.)
- Caching - it's a client side script, which means by default it'll get cached in the visitor's browser after the initial request from the server by default. Caching can dramatically speed up page rendering in the browser.
- SEO friendly - because the UI logic is embedded in a file that doesn't get spidered or indexed according to conventional wisdom, it can help you keep your content clearer and more keyword rich. Search engines crawling your site wont get the UI elements and instead get the pure undiluted content which your page is actually about. This may help them index it better, though that's yet to be quantified. And, depending how you implement your site navigation, you can get the best of both worlds, the spider can find and crawl your links as pure anchors, and the UI can present them to visitors eyeballs in the most visually appropriate fashion for your design.
- Client-side - another potential advantage of this approach is that the visitors machine will render the UI. I've hosted sites on servers that were unacceptably slow on 5 page serves out of 10. The consequence of such a scenario is often that the visitor's browser has not received enough HTML box definition to ascertain the widths and heights of containers and thus it is incapable of rendering (beginning to actually draw) the site so the visitor can see it. By reducing the amount of HTML you are relying on the server to spit out, you reduce that wait time. And by relying on the client machine to render the UI, you can control more of that process using events. So for example if you are building a database application inside of your "pretty design" then you can set up your templates to display the data as it's becoming available, or choose to show a "loading .. please wait" message, or whatever you desire while you are awaiting the server's completed response. This brings more of that control into the hands of folks who are keenly interested in the user experience -- the folks doing the front end!
And, the cons
In my experience the main con has been that HTML folks often don't have a good understanding of JavaScript.
They can do it when push comes to shove, but they don't think in JavaScript. Heck, in my experience some
don't even think in HTML and CSS (instead relying on WYSIWYG or an IDE for example... sometimes to be fast,
sometimes because that's how they learned it). I think as we all work to hone our craft based on the types of
projects that come our way, it's easy to go down either path, sometimes both. So, I'm not poking fun at either
creative approach but instead pointing out that if your process is going to be maintained by someone that isn't
comfortable with JavaScript, there may be a learning curve with this approach.