RainTPL for FAST Templating

[diafol]

Hi All, not the usual, "how can you help me" thread, but a heads-up on a templating engine I've been using for a while called RainTPL. A few users have posted threads of late asking about templates.

I thought I'd give this one a plug, especially as Federico (the author) has just published a speed test page on his site: http://www.raintpl.com/PHP-Template-Engines-Speed-Test/

If you've used templaters like Smarty, RainTPL should seem very simple to use - just "8 tags and 2 methods".

If you're interested, I've documented a multilingual implementation at diafol.org/rain.php , which is itself built on RainTPL.

Anybody have any views on RainTPL or any other templater?

[pritaeas]

For me, RainRpl is a valid option for a new site. The trouble of switching existing sites is not one I wish to take. Not because it is hard, but I'm just too lazy. I'm so used to my own set of tools, it's the first thing I copy.

Next to that, is the fact that I do not always make my own design. Some of the designers also have grown used to smarty (and the plugins I use).

All in all, I think it is a very nice templating engine to start using.

[chrishea]

I spent a bit of time with RainTPL the last time that Ardav mentioned it in a post and I agree that it is pretty simple and straightforward. I would certainly consider it for something new. Retrofitting it would need some meaningful payback to make it worthwhile.

[pritaeas]

A bit disappointing... I really expecting this to turn into half a flamewar, or at least something interesting. Apparantly nobody with opinions here.

[diafol]

Yep, bit of a damp squib. Thought it would generate some discussion wrt. template engines.

I used to use Smarty, but I found it too cumbersome. How's that for a start?

[mschroeder]

Alright, I'll bite the bullet and throw some fuel on the fire.

Having more than a decade of php development under my belt now, I've run the gamut of template engines. I've even spun a few of my own over the years, but alas I've settled back into using purely php in my views.

Template engines are great in theory, they separate your logic from your display. Until you work with a designer who takes one look at your template language and pitches a fit, because they don't get it, and they don't want to get it.

In my opinion it is reinventing the wheel, adding a layer to your view rendering (in mvc terms) that takes a template and then has to parse over your code to replace some form of tags with values and also be able to find and execute logic, that just replaces it with php.

I've yet to find substantial reason to defend using {$variable} vs. <?php echo $variable;?> The earlier requires understanding of the template library and Rain is very simple compared to most. But when looking at some of the popular engines out there the template syntax becomes infinitely more complex than using natural php.

Now, if you want to talk REAL template languages, than I would highly advocate XSLT. I've used this in several cases and have really enjoyed working with it as a template engine/language. Using the PHP XSL extension ( http://php.net/manual/en/book.xsl.php ) you can simply serialize your view object into an XML representation, provide it to an XSLTProcessor with an xsl template object and you get the output. XSLT is extremely powerful and provides a very extensive library of functions and methods for working with xml. You can harness the power of a W3 spec. XML, XSLT, XPath, XQuery. It is also extremely fast. Happy to provide an example site via PM if anyone is interested. My biggest gripe is libxslt has not/will not update to support the 2.0 spec, at least as of yet.

[pritaeas]

I've done XSLT's too. Mostly when using MSSQL, because it can output data as XML. Directly mapping your query result onto an XSLT was something I really liked.

[diafol]

{loop name="arrayname"}
  <option value="{$value}">{$value}</option>
{/loop}

against

<?php
 foreach($arrayname as $item){
?>
  <option value="<?php echo $item;?>"><?php echo $item;?></option>
<?php
}
?>

or

<?php
 foreach($arrayname as $item){
  echo "<option value=\"$item\">$item</option>";
}
?>

or any myriad other combinations. Have to say, not much difference in 1 and 3. 2 is just silly. However, I do like the idea of not having php tags in my html.

XSLT - had a go at this a while ago, never got into it. Perhaps it's worth another look? Is it worth it for simple pages that just need the odd loop, include and variable placeholder (e.g. traditional templater)?

Although the functionality of XSLT has been listed, is it a viable option for general practitioner or enthusiastic hobbyist (like myself)? Or is it more for professional standard programmers?

[diafol]

**Sorry, but forgot to ask. I know XML can be used as a data store for XSL, but can XSLT deal with DB too? From what I gather mysql has to form xml data first. If so, isn't this a bit fiddly? I'd rather keep my data in a DB without having to dump it to XML and then parsing it into XHTML via XSLT.

[mschroeder]

But what about the simplicity of:

<?php foreach( $users as $user): ?>
<option value="<?php echo $value; ?>"><?php echo $value; ?></option>
<?php endforeach; ?>

There is shorthand syntax for almost, if not, all control structures in php.
If you were to use short php tags, which I will never, advocate you'd get <?=$value?> instead.

But it really is just semantics, if it works for your needs and it is a simple solution than it is a good solution.

As far as xml/xslt/xpath/xquery goes, it is a really powerful set of tools because they are not just relevant to php. In fact most browsers have very good support natively.

The following is simplified from a w3school example.

<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- Edited by XMLSpy® -->
<catalog>
	<cd>
		<title>Empire Burlesque</title>
		<artist>Bob Dylan</artist>
		<country>USA</country>
		<company>Columbia</company>
		<price>10.90</price>
		<year>1985</year>
	</cd>
</catalog>

<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- Edited by XMLSpy® -->
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
  <html>
  <body>
    <h2>My CD Collection</h2>
    <table border="1">
      <tr bgcolor="#9acd32">
        <th>Title</th>
        <th>Artist</th>
      </tr>
      <tr>
        <td><xsl:value-of select="catalog/cd/title" /></td>
        <td><xsl:value-of select="catalog/cd/artist" /></td>
      </tr>
    </table>
  </body>
  </html>
</xsl:template>
</xsl:stylesheet>

The general idea is that you supply an xml document to an xslt template and the template then pulls its data from the xml.

In PHP the transformation would work something like:

$doc = new DOMDocument();
$xsl = new XSLTProcessor();

$doc->load('/path/to/xsl/template.xsl');
$xsl->importStyleSheet($doc);

//Load XML from string		
$doc->loadXML('xml string...');
$html = $xsl->transformToXML($doc);
		
echo $html;

[diafol]

@ms
Thanks for that. I was just wondering whether XSLT can grab data from mysql or does everything have to pass through xml? I had a little go with xquery a while back, but I couldn't understand what advantage holding data in xml has over a mysql db.

Excuse my ignorance. I'm just trying to get to grips with why store data as xml in the first place (other than the obvious universal format).

[mschroeder]

-ardav

Since xml is very well structured it would be relatively trivial to serialize an array or object returned from a database into xml automatically if needed. It also gives a very defined point to introduce caching into your system where the cache would be an xml fragment or entire document.

You're not really storing data in the xml long-term you're more so using it as an intermediate.

When I first played with the concept I was really worried about the performance overhead that the serializing to xml might introduce, but I was really surprised when I started benchmarking it in terms of speed and memory usage.

[diafol]

OK, I think I got you. As I assumed, the xml is just a temporary snapshot of the data 'as is/was' from the DB. So you'd still need the DB as your main data store. Updating the DB would be via php mysql (or other DB) functions I assume - you wouldn't use xml as an intermediate for DB updating/insertion?

You've given me food for thought. I may consider using xslt in my next mini project.

Thanks again.

[chrishea]

I looked at RainTPL and pretty quickly I got it. I played with it and tried a few things and they worked. It will take some more time to get any good with it but it doesn't seem difficult or intimidating. I have one application where I think it might be beneficial but I'm not sure if the retrofit effort would be worth it.

Previously, I tried to understand Smarty and I never got there. With more time I probably would but I didn't have a compelling need so I didn't pursue it. Just had a quick look at XSL/XSLT and it seems a bit like the Smarty situation. With some time I can probably figure it out but I'm not really sure that it's worth it (and still no compelling reason).

Thus, for potential occasional use, I think that RainTPL is the winner based strictly on simplicity. If I was to use a template system for every new project then there might be more capabilities in XSL or Smarty that would make one of them a better choice. I understand that there is some theoretical benefit in separating the view part from the logic and variables but I'm not sure if there is a real payback to make it worthwhile. Any thoughts on (real) benefits?

[pritaeas]

I think the real benefit is only when you allow the user to modify/switch templates on the fly. One nice example would be a simple report generator using mssql (which outputs xml) in combination with a query builder and an xslt. Both the query and the xslt were stored in the db, and so could be easily changed to suit new needs.

[mschroeder]

I understand that there is some theoretical benefit in separating the view part from the logic and variables but I'm not sure if there is a real payback to make it worthwhile. Any thoughts on (real) benefits?

It is not a theoretical benefit to separate the view from logic, it is a real benefit. By separating the view from your logic you create another component that can be replaced on the fly.

For example, you have a site that sells a product. We'll say the url is domain.com/product/####, to view a specific product. When a user browses to that url, the system is looking for a format parameter (format/html, format/json, format/xml) it doesn't find one so the controller defaults to rendering the default html view. This might produce a page of a shopping cart for someone to buy the product directly from you. Now you have a third party who comes to you and says they would also like to sell your cogs in their store.

In a system where the view and logic is intermixed, you would need to replicate the page and/or code and adapt it to be some kind of readable format. If the logic and view is separated, its just a matter of rendering a different view. So the additional retailer says I can read any kind of json data in, so you create a json view that takes an array representation of your product model and json_encode it, and serve it as json.

To read the json feed the user simple reads the url domain.com/product/####/format/json. The logic is exactly the same as displaying the product and technically the output is identical it is just represented differently.

Same goes for an additional retailer, except their system best handles xml. So you create an xml view that renders your product model into an xml feed and serves that. They browse to domain.com/product/####/format/xml. Again same logic, all in one place but a unique view of the data.

My experiences with template engines have been very mixed. I don't really see the benefit of using {$something} vs <?php echo $something;?>. You remove the php from your templates but the user still needs to learn the template language which is wildly different system to system where as php is always php.

[diafol]

The example of the vendor was nice. I probably won't need it (yet).

The advantage of template placeholders {$var} vs. <?php echo $var;?> I suppose is a personal thing. It at least does away with the "do I enclose html in my php output or do I shove in loads of php snips into my html?". I always found it really unsatisfactory to see php and html all over the place. OK, it can be argued that the php hasn't really been removed, just replaced by a series of placeholders, but for me that in itself is an improvement. Uncluttered HTML.

[diafol]

Just received a PM from OcRedF - thanks mate - describing speed tests conducted with the leading templaters vs. php. Really interesting. Seems RainTPL is really fast:

http://www.phpcomparison.net/