2009/5/25 Robert Cummings <robert@xxxxxxxxxxxxx>: > 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. Time of the month? >> 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. Ok, in my mind this is not a templating system, this is an HTML library and could just as easily be built in pure PHP without needing your custom XML-based syntax. And IMHO it would be the better for it, but that's just an opinion. >> * 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. So what you actually mean is a macro language. That's basically what you have here, but I still view it as unnecessary. >> >> "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. I don't disagree with that. However, you didn't say why this is a good thing. I prefer the dynamic parts of my templates to stick out when I'm working with them, but again this is just my preference. >> >> * 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. That it affects the readability of the code/content is your opinion. I'm pretty adept at reading tiny snippets of PHP integrated with HTML, probably in much the same way that you're pretty adept at reading your own custom syntax. The main difference I see is that I don't have to explain my templates to other people so long as they know PHP. >> * 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. Actually caching is an integral part of my template engine because it's that integration that gives me the performance I desire. And what's this intermediate run-time step you refer to? I get the cached copy, and build it if it doesn't exist. This lets me control how often a piece of content is regenerated. How is that different to the way your compilation step operates? >> * 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. Hold the phone... you wrap up complex HTML arrangements into reusable chunks? Hey, I do that too - they're called templates!! >> * 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*. I wasn't comparing it to smarty. I too work with non-programmer content writers, but that doesn't stop them writing stuff that slots straight into my templating system. They build plain HTML files just without the layout around them. For the few that use software like Dreamweaver to write their content I have a set of scripts that will clean the crud before storing them in the git repository, but beyond that no other changes are necessary. >> * 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. Now you've lost me. You stated that this was one of the benefits of using your template engine, but now you say that the templates themselves are not actually involved in the compliance checks? So how exactly do they provide this benefit? As I understand it (and I really hope my ignorance doesn't get in the way of this), your compile phase spits out a list of all the valid URLs for the site. I'm sure glad I don't use it for one of my sites which, according to Google, has "about 1,290,000" pages - and that's just the ones it has indexed. I really don't see this as a major benefit. >> * 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. Ok, if I understand you correctly your reference to fixed parameters order is talking about functions, yes? Nothing in my template implementation uses function arguments to pass data to templates. As far as "a big fugly array" goes, I can kinda see what you mean here, but I have certainly never had an issue passing data to a template via an array. In fact if anything it works perfectly naturally. In addition my class-based template system uses member variables on objects to pass a lot of the data, something that has likewise never given me any issues. >> 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. Ok, your previous "answers" have sort of answered this one. I was referring to how you would insert dynamic content into an HTML tag using an XML-based syntax, but since your HTML is built by an expanding macro that negates the question somewhat. >> 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. I don't believe I've put forward any "false" arguments, just opinions you disagree with. There's a subtle but massive difference. >> 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. Hang on, even if you "compile" a template, you still need to "run" it to do dynamic replacements. So I'm still a bit unclear on what precisely your template engine has saved me at runtime. A static template file using the current iteration of my template system involves nothing more than outputting a cached header, the raw template file and a cached footer. That's two memcached hits and two file hits (one for the script and one for the template). In yours, and I'm guessing this based on what you've said, it's served as a static file? In that case how do you deal with displaying the logged in username? Oh, the header would then be built by running a template? Ok, so you've saved one memcached hit [1] against mine. Yeah, I'm converted. Thanks for showing me the light. [2] -Stuart [1] Taking a random page on one of my sites and looking at the profiled time taken to get and output the footer content this represents a saving of......... 0.000188 seconds. [2] This is my sarcasm sign and I proudly hold it aloft at this point. -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
