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. I believe I have a pretty firm grasp on how our template engine works. You have a macro language as part of it; I can appreciate that and have used similar systems back when I was writing CGI scripts in C, but I still see little benefit to that over properly organised logically separated PHP layers. However, as I keep saying this is simply my opinion based on my experience so far. I'm absolutely certain there are better ways to accomplish the same goals - I have been proved wrong on many occasions, but if you're not willing to explain to me why your template engine is a better option then I will indeed continue with my "happy coding" without knowing any better. Good day sir. -Stuart -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
