Stuart wrote:
2009/5/25 Robert Cummings <>:
I continued the discussion with Nathan.

I too have had an off-list discussion with Nathan on this topic, and a
productive one at that.

which would probably be a good time for me to step back in; having had a nice little inside in to both Robert and Stuarts template systems, and indeed way(s) of doing things. Also thanks to everybody else who made suggestions and gave input - it was all appreciated.

I'm far from making a final decision, as I've decided to approach this by setting a few guidelines and a wishlist, then either finding / modifying something to do the job, or creating something from scratch.

Both Rob and Stuarts systems were more in common than they may think, focus in both was on performance, and only making set data available to the templates (whether pushing or pulling).

The syntax did differ though, and functionality aside this is probably one of the most important aspects (imho).

Markup & XML sits well with me (and most) because we are web developers and use it daily.

PHP syntax also sits well because we also use it daily.

The fact remains though that this "feels like" (and possibly is) a different job which requires something different. Both XHTML and PHP do their job well - just as ecma(java)script and css do theirs.

However none of these technologies / languages are suited and dedicated to converting provided data in to specified output; specifically, and only, xhtml.

XSL Templates are near perfect, built for the job, and very powerful - but time hasn't favoured them well; and until (if ever) a wide spread adoption happens something else needs to fill the gap.

Template Specific Thoughts:

Smarty, Stuarts Engine, Robs Engine, PHPLIB and many more had one common theme, they all limited the data available. My terminology of limited perhaps sounds wrong, so maybe "make specified selected data available" or "provide access to the view" will make more sense. Inline with layered and tiered application design this makes perfect sense; thus..

A template /should/ only be able to access the data made available to it, nothing else. Whether it requests the data or the data is provided is covered later. If it doesn't have all the data needed then this needs reviewed and the application needs changed to provide it. Not the template engine bastardized to accommodate a limited app.

A template ~should~ have unique yet easy to understand syntax, something that complements xhtml and provides all needed functionality. (IMHO it should not be php syntax)

A template engine must stick within it's role boundaries, it's not a cache engine, its not php, its not xhtml, its not for implementing functionality - it is simply and purely to do its job - take data, populate an xhtml template with it and return the result - nothing more, nothing less.

Push vs Pull.

This is a much bigger issue than I thought, and perhaps is the crux of the whole thing. I can see two clear approaches;

Firstly, (the common one)
- app passes data and a template to the template engine
- template engine merges it together and passes back
- app does as it pleases with data (sends it to client, caches it, fires it in an email - whatever)

Secondly, (uncomment)
[think modular]
- app provides an api / gateway to views of data
- template engine requests view(s) specified in template from app
- template engine populates template modules with data & sends output to

I guess the first is template engine as a Util / Service - and the second is template engine as a Layer / App.

There are pros and cons in each design, concentrating on the second design for now - this brings in a lot of scope which seems to fit well both practically and architecturally.

The freedom to be able to specify in template that...

this is template module "latest posts", it is bound to the data view (or data provider) "latest posts(8)" whilst overall combining template (page) is comprised of modules x,y and z - here, here and here.

...really appeals to me; certainly in this scenario where you request (pull) from the application rather than make it all available. This way you only ever perform the business logic required for the information available. The counter part of making everything available incase it may be used is ridiculous (and makes me think coldfusion for some reason??).

Architecturally this appears to be good - it's the presentation tier being a presentation tier, the logic tier knows nothing of the presentation tier and simply serves up what is requested. However thats only on the one side of the tier - on the other side we have a huge gaping hole where functionality should be (cache, compilation, delivery) etc, which would require another, as yet unknown layer (or 2).

The abstraction and separation of concerns in this setup really appeals - but practically I'm not sure if the time spent implementing on a small or even medium sized project would be worth it. Still appeals massively though - pull makes more logical sense to me.

Meanwhile, we have the first option, the way it's done, "push" the data - specify a template for that data and let template engine X do the merging. IMHO a clean, simple, lightweight implementation wouldn't be the hardest thing to make, and hundreds of apps are freely available all ready.

Push vs Pull Conclusion
Mentally I'm sticking with "pull" for a long term goal, however practically I'm going to look at creating "push"; which isn't hard and focussing specifically on template syntax, which is were I'm going next :p


As mentioned previously I strongly feel all the current offerings I've seen are not ideal, the syntax is just a bit wrong

preference goes to smarty/phplib style of syntax {$var.child} for only one reason.. because it's not as intertwined as:
echo '<li>'. $var->child . '</li>';
//simple example but you know how messy this can get
likewise it's not as ..?.. as xslt nor is it as potentially confusing as two versions of markup in the same document.

however, I still don't like it - it's just a workaround imho, a temporary measure.

between the last line and here there is a massive trail of thought I can't even begin to type out, and it'd be v boring. BUT it leads me to the following..

An extended version of xhtml, with a simple dtd, specifically for templates. This isn't intertwined or alternative markup, it's enhanced with more attributes.. consider

<div id="comments" datasource="blog.recentcomment">
    <strong data="title" /><br /> ..PROBLEM..

and here in and there in lies the great big feckin problems which means we'll never have a proper solution.

..PROBLEM.. how do we specify what the content of problem area is? without introducing a new tag rather than just an attribute?

making a template syntax is simple, while you do block elements, the second you hit inline elements you are stuffed.

<b> is the bane of our lives, because we can't represent inline elements in any language bar xhtml, we work with blocks of everything. Consider drawing API's, you can draw a circle inside a square easily, the code is just:
object.drawSquare( x , y , w , h );
object.drawCircle( x , y , r);
it's never
object.drawSquare( x ,{object.drawCircle( x , y , r)} y , w , h ); //lol

back in xhtml world, to mark off a segment as <b> without using the syntax or sending an xhtml fragment in a var we'd have to do it using an instruction with offsets and positions.
$string = 'some content here';
$boldBit = substr( $string , 5 , 7);
// .. more code

so the syntax of xhtml doesn't really fit any programming language (?)

interestingly I finished that ..PROBLEM.. off mentally and came up with a tag like <data data="whatever" /> which may as well just be <value-of data="whatever" /> which is just xslt.

square one.

sub thought.. is that an xslt pre processor which figured out what data the xsl needs, then provides it as xml and delivers client side ready for rendering would be nice.

ultimately though, I feel I'm getting no-where, syntax syntax syntax - I re-iterate, I'll have the solution to this when this can be accomplished


if( isset($comments) && is_array($comments) && count($comments) > 0 ) {
  echo '<h2>Comments</h2>';
  echo '<div id="comments">';
  foreach( $comments as $index => $comment ) {
    echo '<a href="' . $comment->link . '">';
    echo $comment->title;
    echo '</a>';
  echo '</div>';
} else {
  echo '<h3>No Comments</h3>';

without php and without xml style markup (unless it's by extension of xhtml with data attributes)

that was a big one!

regards & any thoughts more than welcome.

PHP General Mailing List (
To unsubscribe, visit:

Reply via email to