Finally somebody mentioned XSL Transformations. Time is relative because as you 
need time to learn an API to produce quickly only after a while, thanks to 
knowledge and confidence, XSL is the same with the advantage that you transform 
a data structure, rather than work over raw programming language ( portability 
and re-usability )

I wrote a post in my blog about this long thread, hope you'll get some point:
http://webreflection.blogspot.com/2009/05/template-engine-why-bother-xml-xslt.html

Best Regards


> Date: Mon, 25 May 2009 23:44:43 +0100
> From: nrix...@gmail.com
> To: stut...@gmail.com
> CC: rob...@interjinn.com; linuxmanmi...@gmail.com; tedd.sperl...@gmail.com; 
> php-general@lists.php.net
> Subject: Re: [PHP] templating engine options
> 
> Stuart wrote:
> > 2009/5/25 Robert Cummings <rob...@interjinn.com>:
> >> 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
> 

_________________________________________________________________
Windows Live™: Keep your life in sync. Check it out!
http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009

Reply via email to