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: nrixham@xxxxxxxxx > To: stuttle@xxxxxxxxx > CC: robert@xxxxxxxxxxxxx; linuxmanmikec@xxxxxxxxx; tedd.sperling@xxxxxxxxx; php-general@xxxxxxxxxxxxx > Subject: Re: templating engine options > > 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 > _________________________________________________________________ Windows Live™: Keep your life in sync. Check it out! http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009
