Page 1 of 2
MVC | Smarty Templates vs. XSL Transformation
Posted: Tue Jul 10, 2007 2:02 pm
by Behzad
I was reading Wikipedia's article about Smarty at
http://en.wikipedia.org/wiki/Smarty, where I faced with an interesting link to
http://www.devpapers.com/article/18 which contains an artcile entitled "Smarty vs. XML/XSLT".
I never knew there is another way to separate business logic from presentation except MVC (implemented by Template Engines). XSLT is a new way to generate HTML on-the-fly. It needs two files: an XML file which contains dynamic data, and an XSL Stylesheet document.
There are some people that are using the XSLT approach, such as Tony Marston
http://www.tonymarston.net/. He claims:
I did read about other templating engines that are available for PHP, but as these are written in PHP and tied to PHP I rejected them as I wanted something that was totally independent of the underlying language and preferably written to 'open' standards and therefore accessible to a larger community.
I have two problems with XSLT. Firstly, it is slow, because XML is a text file and it needs to be parsed before the transformation. Of course, PHP should be parsed too, but adding another level to the interpretation kills the speed. Secondly, how do you generate that dynamic XML file which contains data? I think that we need to have place-holders in a XML file and fill them using a Template Engine! The second approach could be using PHP 5's DOM functions. However, in both cases it sounds too much work, I think it is very slow and it requires very hard work to implement MVC.
I'm really eager to know your views on this subject. What do you think?
Posted: Tue Jul 10, 2007 3:52 pm
by stereofrog
Most people tend to use pure php templates, because php is already a templating language and there's no sense to put another one over it.
XML is great for semi-static sites, where the data doesn't change frequently, so it's possible to cache xml files produced by backend. Also xml is quite handy when you need to produce several formats at once, e.g. html and pdf.
Smarty? I can't think of any good use for smarty.

Posted: Tue Jul 10, 2007 4:05 pm
by Ambush Commander
Firstly, it is slow, because XML is a text file and it needs to be parsed before the transformation.
Not necessarily. Many times data will be put directly into a DOM object, which requires no parsing at all. Also, parsing XML is usually faster than accessing a database, if you need a XML file cache.
Secondly, how do you generate that dynamic XML file which contains data? I think that we need to have place-holders in a XML file and fill them using a Template Engine!
DOM!!!
However, in both cases it sounds too much work, I think it is very slow and it requires very hard work to implement MVC.
SimpleXML offers a simpler (albeit not as comprehensive) treatment of XML. If DOM is too heavy for you and you don't feel like building some wrapper convenience functions around it, SimpleXML may work well.
Posted: Tue Jul 10, 2007 4:39 pm
by Behzad
Also xml is quite handy when you need to produce several formats at once, e.g. html and pdf.
WOW! Very interesting!
parsing XML is usually faster than accessing a database, if you need a XML file cache.
It's a little unbelievable for me to accept that parsing an XML file is faster than reading from a database. Database stores the data in binary file format, and creates indexes over it to make the data-retrieval faster, so you can find a record in the order of O(log n). The indexes are available in RAM which could be considered as some sort of cache.
But in XML, you need to parse the whole text file and make sure it is well-formed, then read it sequentially to find your desired record in the order of O(n). I'm a student and I'm sure about what I'm saying. But this is what I've learned. Please correct me if I'm wrong.
Posted: Tue Jul 10, 2007 6:08 pm
by Ambush Commander
It's a little unbelievable for me to accept that parsing an XML file is faster than reading from a database.
You can test it yourself.
Database stores the data in binary file format, and creates indexes over it to make the data-retrieval faster, so you can find a record in the order of O(log n). The indexes are available in RAM which could be considered as some sort of cache.
Apples and oranges: XML doesn't scale very well for doing "database" style operations such as searching and indexing. But if you need to retrieve all the data, reading it directly from disk is usually faster than querying an external process. Note that you may want to use PHP's native serialize() format (which is even faster) if interoperability isn't a huge concern.
But in XML, you need to parse the whole text file and make sure it is well-formed
One of the benefits (some say drawbacks) of XML is that it is extremely strict, making parsing algorithms much faster and smaller than those for HTML.
, then read it sequentially to find your desired record in the order of O(n). I'm a student and I'm sure about what I'm saying. But this is what I've learned. Please correct me if I'm wrong.
You are mostly correct. We're simply talking about different types of operations.
Posted: Wed Jul 11, 2007 10:13 pm
by AKA Panama Jack
Actually XML/XSLT is going to be far slower in just about every instance than using a template engine. This is because the XML file data coupled with the XSLT stylesheet tends to be LARGER than the same HTML document created by a template engine. It just the nature of XML and how it over complicates things with the tag structure. Where you might have an 50k HTML document created by a template engine you end up with usually a double sized XML/XSLT document.
Now you will have people saying but the internet is faster so it doesn't matter how much data is being sent. You won't notice it.
BAH!!!
I spent the last week visiting family and using a DIALUP connection. You don't notice a problem if you are on a broadband connection but when you are on a DIALUP that extra data is a PAIN IN THE BUTT.

I never realized how POORLY some sites were designed until I tried visiting them on DIALUP. With my cable;e connection they popped right up but with DIALUP some took over a minute to display.
Just remember that there are still far more people on slow 56K DIALUP connections than on DSL/Cable.
Posted: Thu Jul 12, 2007 1:20 am
by Christopher
Whenever I see the name Tony Marston pop up there is also a warning flag. The guy is notorious for weird bad design philosophy. I know he used to drive guys whose opinions I really respect completely nuts. I would find a solid rebuttal of whichever of his ideas you are interested in and head in the direction the rebuttal suggests.
Posted: Thu Jul 12, 2007 2:24 am
by Maugrim_The_Reaper
Mark, even I'm on dial-up at home

. And yes, XSLT based pages are more often than not slower on dial up since there is more to have trundle down the telecom-monopoly inspired 46.6 kps bandwidth. This isn't to rain on the parade of a technology, it's still well worth the time to learn it and it puts the templating question in perspective.
If you want even more speed than Smarty (not saying XSLT+XML is slow server side), Mark has Template-Lite you can look at. It offers a Smarty compatible tag library which is smaller and more efficient.
Posted: Thu Jul 12, 2007 5:48 am
by alex.barylski
arborint wrote:Whenever I see the name Tony Marston pop up there is also a warning flag. The guy is notorious for weird bad design philosophy. I know he used to drive guys whose opinions I really respect completely nuts. I would find a solid rebuttal of whichever of his ideas you are interested in and head in the direction the rebuttal suggests.
The fact you refuse to look at his perspective rationally, suggests you are as far right wing as he is left. Does that mean your both wrong?
I really need/have/want to see a full blown application developed solely by you. Complete with a GUI and everything, not just simple disparate classes which hilite the theory behind DI or front controllers and command objects.
Posted: Thu Jul 12, 2007 10:38 am
by AKA Panama Jack
Maugrim_The_Reaper wrote:Mark, even I'm on dial-up at home

.
I feel for you.

I was pulling my hair out for a week. I guess I have become too jaded.

Posted: Thu Jul 12, 2007 1:10 pm
by alex.barylski
I can't even fathom using dialup...last time I used it was back in 1999/2000 when I was living in a crappy apartment and had to borrow my dads dialup account details. One good thing about dialup is it's portabaility.
The local telecom was quite early out of the gates pushing highspeed DSL. It wasn't long after that a national media provider jumped on the band wagon and started offering Cable. Yup, once you try crack (aka: hispeed) you never go back. Dialup would consume so much time in waiting for information or browsing the web...I would go craaaaaaaaaazy....

Posted: Thu Jul 12, 2007 3:41 pm
by Ambush Commander
Back on topic...
Actually XML/XSLT is going to be far slower in just about every instance than using a template engine. This is because the XML file data coupled with the XSLT stylesheet tends to be LARGER than the same HTML document created by a template engine. It just the nature of XML and how it over complicates things with the tag structure. Where you might have an 50k HTML document created by a template engine you end up with usually a double sized XML/XSLT document.
Because browser XSLT support is spotty, I favor server-side processing of XML/XSLT, and then serving the result HTML to the browser (allowing the user to download the original XML file, but not shoving it in their face). Whether or not an XSLT processor is slower than using a template engine is another question altogether.
I spent the last week visiting family and using a DIALUP connection. You don't notice a problem if you are on a broadband connection but when you are on a DIALUP that extra data is a PAIN IN THE BUTT. Razz I never realized how POORLY some sites were designed until I tried visiting them on DIALUP. With my cable;e connection they popped right up but with DIALUP some took over a minute to display.
In general, multiple resources in a document (images, flash, etc.) are the biggest things that drag down speed, not plain old HTML, due to their size and also because of the network latency that results from having to talk to the server multiple times. Also, gzip'ing content can greatly aid dialup users: for text content the algorithm can reduce sizes to 25% of the original.
Whenever I see the name Tony Marston pop up there is also a warning flag. The guy is notorious for weird bad design philosophy. I know he used to drive guys whose opinions I really respect completely nuts. I would find a solid rebuttal of whichever of his ideas you are interested in and head in the direction the rebuttal suggests.
Martin Fowler is very much in favor of the XML -> HTML using a transformation, although I think he's given up on XSLT due to its verbose-ness as an XML format and other problems (he's using Ruby instead to do his transformations, which I must admit is not something I can use). In this case, shoot the messenger, not the message.
Posted: Thu Jul 12, 2007 5:13 pm
by Christopher
Ambush Commander wrote:Martin Fowler is very much in favor of the XML -> HTML using a transformation, although I think he's given up on XSLT due to its verbose-ness as an XML format and other problems (he's using Ruby instead to do his transformations, which I must admit is not something I can use). In this case, shoot the messenger, not the message.
I agree with you assessment. I also think that CSS has sucked up much of the oxygen that was fueling XSL. There are several reasons. First CSS is simpler to implement and read. CSS performs better because it is all in the browser and supported. I don't think that transforms ended up being as handy given the trouble and the alternatives (e.g., Ruby and PHP), and it ends up that there is not a much XML server side as once thought, so you are converting data to XML as an additional step in an already slow process.
And I would definitely be wary of that messenger.
Posted: Sun Jul 15, 2007 7:59 am
by WebbieDave
When someone gripes about Smarty being a template engine stacked on top of another template engine, you need to stand up to that person and tell them that they're 100% right. Though there may be something to be said about employing a framework that helps to enforce a desired architectural pattern, the overhead (seriously, think about the overhead here) and new "language" makes Smarty not-so-Smarty after all. You can achieve the basics of Smarty (assign, display) in a few lines of PHP. Best of all, when making your templates, you get to use the most popular template language ever created.
Code: Select all
<? // Webbiedave says try it!
if (!defined('TEMPLATE_INCLUDE_DIR')) define('TEMPLATE_INCLUDE_DIR', dirname(__FILE__) . '/');
class Template
{
private $_templateVars = array();
function assign($name, $value)
{
if (!strlen($name)) return;
$this->_templateVars[$name] = $value;
}
function display($_viewName)
{
foreach ($this->_templateVars as $_key => &$_val) {
$$_key = $_val;
}
$_errorSetting = ini_get('display_errors');
ini_set('display_errors', 0);
include TEMPLATE_INCLUDE_DIR . $_viewName . '.tpl.php';
ini_set('display_errors', $_errorSetting);
}
}
?>
You get the idea. Plus, aren't you sick of doing $smarty.const.WHAT_THE
Oh, and how can Smarty (or XSL transformations, for that matter) ever be as fast or flexible as doing something like this?
Posted: Sun Jul 15, 2007 12:29 pm
by AKA Panama Jack
It can...
I should know since I developed a faster and smaller version of Smarty.

You have to remember that the template file is onlay parsed ONCE and converted into a PHP program that is called everytime afterwards without any need to parse the original.