On Mon, 2009-05-25 at 19:56 +0100, Stuart wrote: > 2009/5/25 Robert Cummings <robert@xxxxxxxxxxxxx>: > > 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. > > Interesting. I make one sarcastic comment (ok, it wasn't the only one, > but it was the only one I highlighed with a footnote) and you decide > to use that to avoid continuing the discussion. If you think I don't > get it then explain it to me - that's the only way I'll learn. If I > didn't know any better I'd think you were using [2] as an excuse not > to justify your point of view. Highlighting it as a footnote underlined your arrogance. I continued the discussion with Nathan. 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
