On Mon, 2009-05-25 at 15:04 +0100, Stuart wrote: > 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. I'm sorry you're taking it personally... you may want to invest some time into growing thicker skin. It's a rare day indeed that I waste the time and energy needed to be hostile to an individual person. I have better things to do. > 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. I guess you don't have flexible includes. One size fits all. But many of my custom tags are akin to functions, they accept variables that allow either compile-time or run-time configuration of a given piece of content. For instance: <jinn:menu title="Some title" accumulators="true" expand="active"> <item caption="About Us" href="//about-us/"> <subMenu> <item caption="Profile" href="//about-us/profile"/> <item caption="Partners" href="//about-us/partners"/> </subMenu> </item> <item caption="Forums" href="//forums/"/> </jinn:menu> This is all expanded at compile time with appropriate div/ul/li/a tags for styling and accessiblity correctness. Saves oodles of time from having to do it by hand everytime. Similarly, the PHP engine isn't doing it on every page request, nor is it being retrieved at run-time from a cache on every request. > * 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. See above example. > > "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. XML, for the most part, walks and talks like HTML. > > * 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. It disrupts the readability of the code/content itself. I use them often enough in various projects. Additionally, there are quirks with PHP tags and newlines being eaten in the content that requires a superfluous newline be added to the content itself. > * 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. No, caching is not the same as a template engine that compiles the actual requested source code. A cache has an intermediate run-time step. My engine can do both styles, but it's an obvious speedup to not need a cache or even my template engine running at request time. > * 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? If I don't need to manually type out all the divs and various other structural elements for HTML (or some other presentation system) then I've saved time. See above example, the syntax is simple, but the content generated less so. As such, I've saved time. > * 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. Sorry, my experience does include non-programmer content writers. My system is not smarty, it should not be confused with smarty. I've used smarty and I don't like smarty *lol*. > * 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. Wrong, this is not a false notion. Your ignorance doesn't make it false. My engine allows tying content validation to the build phase because the build phase knows the final URL, and submits the final URL to the validation engine for validation. Not the template, not the compiled content which will often contain PHP code, but the actual URL for the compiled page is sent to the validation engine. Alternatively the post-handler could retrieve the content itself from the known URL via cURL and submit this to the validation engine. Given this scenario, you have probably realized the dynamic bits are filled in since it's the same as any request by a browser. > * 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. If you don't understand what is meant then I'm not about to teach you. I would guess the majority of readers know exactly what I'm talking about. If you need a hint, go back to the first paragraph of this response. > 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 depends, from whence is the data coming? My engine supports run-time conditional tags that can do this verbatim. The problem is, content is usually encapsulated in a view so I wouldn't be pulling it form the global scope. I don't like the empty() function anyways, it's a kludge since 0 is also considered empty, and I consider 0 a value. Null, false, and the empty string would echo just fine as an empty string and so would not need a conditional around them. I would probably have sorted this in the business logic. > 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. I'm all for different ways of looking at the world, but patently false arguments are annoying. They come up with respect to templates quite often. > 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. The extra step exists whether it occurs at run-time or once at compile-time. The advantage to compile-time is that it occurs once for all subsequent requests. Run-time occurs every time unless a cache is used, in which case the outermost cache request occurs every time. > Have a great day Rob! You too. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
