On Mon, 2009-05-25 at 16:58 +0100, Nathan Rixham wrote: > Robert Cummings wrote: > > On Mon, 2009-05-25 at 15:04 +0100, Stuart wrote: > >> 2009/5/25 Robert Cummings <robert@xxxxxxxxxxxxx>: > >> 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. > > so.. > - in your template you've hard coded data that would typically be > managed by a cms (captions, hrefs, which pages are shown) > - using a syntax that nobody knows > - which removes most of the functionality a web developer wants (such as > choosing which elements, class, ids, additional attributes) This was an example. Some sites don't need a CMS, or the CMS handles the content only and not the navigational elements. Also, I created my fraemwork years and years ago. > I'm a big fan of xslt and xml; but this just seems completely inverse to > every other approach I've seen - it's removed all presentation based > stuff from the presentation layer?? Most template engines are push engines, you push the data into a template object which the template engine then expands. Mine can work this way, but it also works as a pull engine, where the data exists on the view and the template compiles to PHP that then pulls it off the view. > kinda thought the whole point of a template was to be able to specify > the structure of the document and place the data you want where you want > it, in the way you want to. Yes, you can place the data wherever you want. I'm not sure what makes you think you can't. > Not to tell a custom system to give you a block of html code it thinks > is best while you manually specify the data to be used in the html it > generates. (?) You're missing something here, project based custom tags are about centralization of formatting. To change the way the menus appear I would either change the CSS styling, or change the custom compiler. Either way, I then have the option to change all content across the site in a single location. > >> * 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. > > conversely, html is a markup language, then they made xhtml which > conforms to xml syntax; thus (x)html walks and talks like xml. > > again xml rocks; but we already have xsl (transformations) which are > supported by both php on the server side and by most browsers on the > client side - which makes it awesome as you can simply dump out your > data as xml and let the client machine do all the rendering. Also XSL / > XML have had the input from the worlds best, for many years, are > recommended, fully thought out and well supported. Again we get to the issue of content developers. XSL is a language, and in many cases even more difficult to use than PHP itself. Additionally, it requires well-formed documents. When I originally created my template engine it needed to be able to work in non-well-formed environments. It was a cinch to take an existing site and incrementally replace swathes of poorly formed HTML will sub-templates and custom tags. > >> * 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. > > I vaguely agree on this one, it can disrupt the readability of an xhtml > based template - unless you have a decent IDE then it makes no odds. > > new line quirks I'd like to see some examples of though - never came > across this (yet) myself. Got any examples Put the following in a PHP file... it has problems in HTML, and especially when used in plaintext emails where newlines should matter: ****************** <?php $foo1 = 'foo1'; ?> This is an example of newline quirks <?php echo $foo1 ?> You will see this line is joined to the last word in above line. ******************* > > >> * 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. > > can one assume then that this is a publish based system whereby you > republish the "site" / html when you change or update something? (even > if that's just publishing the templates and including them in ouput) It has both options. The engine can be configured to detect content changes and re-compile automatically. Or the whole site can be built on update. Don't confuse this with a static site, templates can be created with plenty of dynamic content and can even wrap existing frameworks or applications. I've used the template engine to create Mediawiki skins and Wordpress skins. One the skins are generated, there's no need for the template engine in the application, so it adds no overhead at run-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. > > can't see how this > > <subMenu> > <item caption="Profile" href="//about-us/profile"/> > <item caption="Partners" href="//about-us/partners"/> > </subMenu> > > is any faster to write than (learning curve not included) > > <ul> > <li><a href="/about-us/profile">Profile</a></li> > <li><a href="/about-us/partners">Partners</a></li> > </ul> > > I can see though that every dev and their dog knows the pure html > example inside out and how to customise it. What you've given above is the most basic HTML syntax for the links, but you've not provided for control of visibility of the submenu if the current page is not the submenu's parent. Nor have you accounted for CSS classes to style the menu (active menu entry, not active menu entry, etc). > > I really don't get the point in using an alternative markup langauge to > generate the same amount of html with no real functional benefits? > > maybe its an example thing.. if it was something like > > <subMenu> > <ul> > <item><li><a href="/href">/caption</a></li></item> > </ul> > </subMenu> > > then I'd get it.. Why manually add the tags when they are specific to the underlying view? Anchors are HTML, custom tags allow the menu to be used in other scenarios if need be. > > >> * 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*. > > confused.. > people write content in the templates and then let the system control > the format of the html thats generated? > not people write content in a cms then the template controls how the > content is displayed? No, content can be written in a CMS, or can be retrieved from the database for lists of data, or can be form elements. The template controls the layout. The content can be pulled from a static template source or it can be pulled from the database or whatever is used to retrieve the content. > >> * 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. > > if its invalid can it fix it? or is it just a report? does it prevent > publishing or? This would be a reporting scenario. Better a report than nothing though, especially when compliance is important. > ps: couldn't any dev just do the same on any site (or even call > http://validator.w3.org/check?uri=URL_HERE ) Yes. I didn't say there weren't other ways to accomplish the same. Having it built into the build system is just convenient. > >> * 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. > > with the example i get you now, first time round i was lost - still > though writing the same amount of jinn code as you would html code but > with less functionality - is that not just as inconvenient and tedious > (to 99% of people) Again, the example was simple, your response HTML was overly simple and didn't encompass everything the menu tag does. > >> 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. > > lol @ the empty() bit - it has its uses though and thankfully we're not > limited to using only empty()! > > >> 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. > > > > there's a time and a place for both though - if you've got a semi static > website or classic brochure site for an sme then yeah precompile; but > this approach can kinda kill an app when a view/page is comprised of > data which changes a few times a second and is different on a per user > basis. (think any major site) I don't follow you... the template stuff is decoupled from the site's business logic. It merely presents data and creates functionality for presenting dynamic data. The template engine can be used for forums, online-stores, wikis, etc. I don't follow how you think it's for static use only. As I said it can be used to create skins for other applications after which it doesn't even get loaded. > all this has actually really helped me - as I now know for sure that I > don't want to use anything at all that has an alternative or > non-standard syntax; telling a ui guy they need to learn something new > and custom just to do some html doesn't sit well with me; I can make > excuses for things most ui guys know anyways. > > Ultimately, i think that xslt and flash / flex are my fav approaches - > and as for a templating engine focused on xhtml/xml output - well there > just isn't a decent one and this is why php was created in the first place? PHP was created to simplify common tasks performed using Perl. That doesn't mean there aren't ways to simplify common tasks performed using PHP. Simplicity certainly is in the eye of the beholder :) > > the one major benefit I see from using a template engine, however good > or bad (with its own syntax, not php), is that it ensures no business > logic is in the presentation layer. Actually, my template engine will happily allow you to use PHP tags if you must. This has been handy in the past for wrapping legacy/crappy systems up in a consistent site layout. > seen one too many mysql_query / while / echo loops in my life. As I said, I'm not trying to convert anyone, only trying to eliminate some of the incorrect information floating around. I have projects where I use PHP "as a template", my own template engine, I've used smarty, I've used EZ components, I've used XSL. I do what needs to be done on a case by case basis. But I do like the conveniences offered by my template engine. I'm going to leave this discussion here since it's eating up too much of my time :) 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
