Stuart wrote:
2009/5/25 Robert Cummings <robert@xxxxxxxxxxxxx>:
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
Syntax
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">
<p>
<strong data="title" /><br /> ..PROBLEM..
</p>
</div>
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
<?php
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 (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
