On Mon, 2009-05-25 at 16:31 +0100, Stuart wrote: > 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. I don't think you understood anything. Anyways, [2] indicates that having this discussion with you is akin to mud wrestling with pigs. I'm not trying to convert anyone. Happy coding. 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
