2009/5/25 Robert Cummings <robert@xxxxxxxxxxxxx>: > On Sun, 2009-05-24 at 21:26 +0100, Stuart wrote: >> 2009/5/24 Nathan Rixham <nrixham@xxxxxxxxx>: >> > LinuxManMikeC wrote: >> >> >> >> On Sun, May 24, 2009 at 11:09 AM, tedd <tedd.sperling@xxxxxxxxx> wrote: >> >>> >> >>> At 12:01 AM +0100 5/24/09, Nathan Rixham wrote: >> >>>> >> >>>> LinuxManMikeC wrote: >> >>>>> >> >>>>> I was recently researching template engines for a small in-house >> >>>>> project, with a bias toward simple and lightweight. I found this >> >>>>> interesting article in my search. I think its worth considering if >> >>>>> you don't need all the bells and whistles of the big template engines. >> >>>>> Simple and elegant. >> >>>>> http://www.massassi.com/php/articles/template_engines/ >> >>>> >> >>>> cheers, it certainly is simple and elegant - however a bit too simple >> >>>> (specifically as it's in template php); gives me immediate visions of a >> >>>> wordpress template - and that's more than enough to scare me off! <lol> >> >>>> >> >>>> regards, >> >>>> >> >>>> nathan >> >>> >> >>> All: >> >>> >> >>> Anytime I see embedded style elements within html, that's more than ample >> >>> warning to make me look elsewhere for the solution -- because IMO that's >> >>> not >> >>> a solution. >> >>> >> >>> I find it interesting that the articles states "the separation of >> >>> business >> >>> logic from presentation" but then combines content with presentation. I >> >>> don't see any real gain here. >> >>> >> >>> My efforts are always trying to separate content from function and >> >>> presentation. Make everything as unobtrusive as you can. Place styling in >> >>> remote css, client-side javascript enhancements unobtrusively, and use >> >>> server-side php/mysql to create secure and accurate function to generate >> >>> the >> >>> proper html and deliver desired content. I can understand someone wanting >> >>> to >> >>> simplify their work, but exchanging one problem for another doesn't cut >> >>> it >> >>> for me. >> >>> >> >>> Cheers, >> >>> >> >>> tedd >> >>> >> >>> >> >> >> >> You're missing the point just because he threw in some old HTML >> >> styling attributes. The main issue is the overhead of added parsing >> >> layers to find where content goes in the HTML. Aren't we already >> >> using a language (PHP) that parses for place holders for dynamic >> >> content within HTML tags? Write the template in XHTML, style it with >> >> CSS, and insert content place marks with PHP short tags. Do the >> >> programming work of calculations, validation, and DB access in another >> >> script which will include the template at the appropriate time. Even >> >> create classes to hold various data sets (think JavaBeans) if you >> >> want. Adding a layer of abstraction just so your designers don't have >> >> to write <?=$var?> is silly at best. At lest that's my opinion. Do >> >> whatever works for you. >> >> >> >> Mike >> > >> > which is lovely, but then you realise you have business logic tied up in the >> > presentation layer, and the client suddenly wants 3 different web based >> > interfaces and a roaming flash version which calls the system via an api; >> > and then you have the joy of telling the client its 6 months work and huge >> > figure to rewrite the application layer to included an abstracted >> > presentation layer, but it could have been avoided months ago with a days >> > worth of work (or even an hours worth) and a different decision. >> >> Using PHP for templates has absolutely no bearing on whether your >> presentation is tied up with your logic or they are completely >> separate. Almost every project I work on day-to-day has at least 2 >> front ends, XHTML and an API. In addition several have mobile versions >> of the presentation layer. All of them use pure PHP to render output. >> >> > all in though, hardly matters on a personal site, or a quick client job >> > where, or a.. I guess there's a place for each technology and method; and we >> > could throw scenarios around all night getting no where. >> >> IMHO there is only one scenario where using a template engine is >> justified and that's when you're working with people who insist on >> using it and you can't talk them round. > > The inverse can just as easily be argued. I've given good points before > as to why a template engine can be useful, good points with no rebuff. > Good points where PHP includes cannot compete. I'm not going to bother > re-hashing them, since you only remember what you want to remember, > similarly you only use what you want to use (and this applies to the PHP > IS-A templating language dogma). > > I use both system where the case presents itself. In fact, I even have > templates that create PHP files that use require(). Have I done something to annoy you lately? You seem to be directing a lot of hostility my way recently. Just wondering. It's true to say that I only remember what I want to remember, but that's only because my head is of a fixed size and I don't want to forget how to walk, eat or sleep. However, when I'm presented with an alternative point of view I give it the attention it deserves. If it can help me in my day-to-day work you can be damn sure I'll remember it, and that I'll use it!! Anyways, I'm assuming you're referring to this post: http://www.mail-archive.com/php-general@xxxxxxxxxxxxx/msg242954.html. Let's take a look at these points shall we... * To simplify the use of parameters so that they can be used in arbitrary order with default values. Parameters to what? I don't really see what you're referring to here. * To allow for the encapsulation of complex content in tag format that benefits from building at compile time and from being encapsulated in custom tags that integrate well with the rest of the HTML body. "integrate well with the rest of the HTML body"?? I guess you mean "it looks the same as the HTML". You consider this a good thing? Each to their own I guess. * To remove the necessaity of constantly moving in and out of PHP tags. What do you have against PHP tags? It's exceedingly cheap to move in and out of PHP tags, especially when compared to other things your site will be doing like connecting to databases or accessing files. * To speed up a site. By this I'm assuming you mean based on performing substitutions in templates at compile time as opposed to runtime. I would argue that if you have large parts of a template that never change, why are they dynamic in the first place? However, this has very little bearing on the speed of a site. My templating system uses several levels of caching that effectively achieve the same result. * To speed up development. This one you're going to need to explain in a bit more detail. How is writing templates in XML any quicker than writing them in PHP? * To make easier to use for non-developers. I hear this argument a lot but I'm yet to meet a designer familiar with something like Smarty who could not pick up basic PHP very quickly. The concepts involved are very similar and utility functions can be written that provide the same operations that Smarty makes available. Actually I should caveat that statement by noting that I did once work with a team of designers who refused to even attempt using PHP, but I put that down to them being scared of it - I failed to talk them round. * To integrate standards compliance checks into the build phase. IMHO this is a false notion. You can check the templates for standards compliance, but not the output. The nature of templates is that they're not complete until they have been filled in with dynamic data. True standards compliance checks can only be performed on the output from a site, not the inputs. * To do sooooooooooooooo many things that are just inconvenient and tedious using intermingled PHP code with fixed parameters order (or alternatively a big fugly array). Again with the "fixed parameters order". What the smeg do you mean by that? And "a big fugly array"? Not sure what you mean by that either. Quick question, how would you implement the following using your XML-based template syntax... <div class="option <?php if (!empty($option_class)) { echo $option_class; } ?>"> ... </div> It's worth noting that I'm simply suggesting a different way of looking at the world. If you have a templating system you're happy with then feel free to continue using it, but I'd encourage you to take the time to consider whether it actually gives you any tangible benefits. I've used Smarty as well as a number of proprietary templating systems and I'm yet to come across one that can justify its existence over simply using PHP. It's also worth noting that when I refer to a "templating system" I mean something that introduces an extra step when running a template. I consider the template classes I use to be a templating system but they do nothing but formalise the process of passing data to other PHP scripts and providing utility functions for them to use. Have a great day Rob! -Stuart -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
