Flexible Content Management System


Template engines living together happily ever after .8 ?

Contributed by on Aug 03, 2002 - 02:23 PM

1. there are (at least) 2 distinct parts to templating :

a. producing the individual block or module function output ("block" template)

b. fitting the pieces together into a page layout ("page" template)

2. with block layout and smarty (used by Encompass) and many other templating systems out there, a template is "filled in" simply by passing variables to the template engine. The engine will do the actual work of producing the output for that template (and how it does that is its business).

3. the template engine will generally start with the "page" template to figure out which pieces it needs, then call some function to fill in each individual "block" template, and then put it all together.

4. many template engines for PHP (including block layout and smarty) "compile" their templates (both "block" and "page") into PHP code

5. there is no (technical) reason why you couldn't have different template engines for "pages" and "blocks". In fact, a 'switch function' at the right place could even decide to let one particular "block" be processed by block layout, the other by Encompass, the third by ModeliXe etc. - remember, processing in this case is generally nothing else than executing some plain PHP code (or compiling the template into PHP first).

6. Block layout has been chosen as the default template engine+language for "block" templates in PostNuke. Good - that means that I, as a module developer, know that if I write my code & templates for that, at least I know my module/block will show some output on all PostNuke installations by default.

The block layout tags aren't much different (conceptually) from other template engines, and for "block" templates, I know I'll only need a small subset of all available tags most of the time anyway, so it's not a big problem.

[perhaps we could even imagine having some automatic translator from Encompass/ModeliXe/... to block layout syntax for simple "block" templates at some point in the future, so that people can develop in one, and release it in the default BL format + their own format (see below)]

7. Block layout has also been chosen for "page" templates in PostNuke. It's basically invoked by calling a single function in index.php to process the "page" template, which then calls other functions to fill in the different "block" templates.

And here is where things get "interesting" :-)

Suppose I have a standard site, with "pages" defined with block layout, and I want to switch to -say- Encompass as "page" template engine, e.g. because I'm using it now and I'm happy with it, or because it offers better/easier control of what goes where on different pages, or whatever.

So here's the situation so far :

a. I don't want to translate all individual "block" templates (from all modules & blocks) into Encompass syntax, but I may want to re-create *some* of them with Encompass anyway (perhaps because I'll be able to make use of feature XYZ better then)

b. I want to be able to define my "page" templates with Encompass

With all the observations above, and with the right 'switch functions' in place, do you see any *major* obstacles in using Encompass as "page" template engine, and a mix of standard block layout + a few customized Encompass templates for "block" templates ?

I don't... Of course, there's the fact that you're "running" 2 template engines now (although most of the processing is done only once, when the templates are "compiled" into PHP code), and there are some issue with how variables from blocks/modules should be passed to the different template engines, etc., but this certainly classifies as "feasible".

How would this compare with the current situation ?

1. blocks and modules are templated in a standard (default) way with block layout - no more digging into code to change "block" output

2. you can override the 'default' templates for each "block" with your own (for different themes), not only in block layout format but also in other template engine languages

3. you can use the template engine of your choice for defining different "page" templates (which is where the major pain of customisation is)

How's that for choice ? I'll leave the detailed analysis & implementation as an exercise for the reader :-)