A Complete List of PHP Template Engines?

Umm… I’ve really started the ball rolling huh ?

I would mostly have to agree with Tezza on the points of XSL-T. I’ve used it a lot in the past with PHP and the Sablotron extension.

I used XML templates and then transformed these after I replaced given XML well formed tags with dynamic data to xHTML and WML with the minimum amount of fuss or trouble.

Very convienent and it is easy to edit the templates as well, though more importantly I think as HarryF stated there is a drawback and that is more load on the server to transform the XML templates.

There is a very notable increase in page load times for example so I’m not so keen to continue using this method, although in saying this I’d definitely use XSL-T again in the future (ie PHP5 ?) if there wasn’t such a time lag brought on by the XSL transformation.

PHP5 and it’s integrated DOM may well be the solution I’m waiting for I think folks ? What do you think Harry ? You know a bit more about PHP5 and we do

XML = Extensible markup language
HTML = HyperText markup language
XHTML = Extensible Hypertext markup language?
[B]XSL(T) = Extensible Stylesheet language (Transformations)[B]

XML, HTML and XHTML are document markup languages. XSLT is not a markup language. XSLT is a turing complete [URL=http://www.topxml.com/xsl/articles/fp/]functional programming language.

Going back to the definition of a template:

2. Computer Science a. A document or file having a preset format, used as a starting point for a particular application so that the format does not have to be recreated each time it is used.

The operating word here is document. XSLT is a program. (Yes, a program file can be a document in another context, but that misses the point. Read Tim Berners Lee’s Principle of Least Power on why html is not a programming language for clarification of this issue.)

My interpretation of this in a web application context is that a template is an HTML document used as a starting point for creating a final HTML document.

To put it into html terms, which example more closely matches the idea of a template?

<h3><?php echo $title; ?></h3>

or

<?php echo "<h3>$title</h3>"; ?>

I would say that the first example could be considered a template (although not necessarily a prototypical example of a template), while the second is a program and not a template.

XSLT was designed to separate presentation from content. Templates can be used to separate presentation from content. This does not make XSLT a template language.

Why is it a good idea to separate presentation from content? Because the two typically have different causes for change and different rates of change. Separating the two makes many changes easier to make.

I prefer to think of Templates as a way to separate HTML from code, the ModelViewController pattern as a way to separate presentation from data, and Templates as a one possible way to implement a View.

Why separate HTML from code? One reason is to take advantage of specialized editors for HTML. Another is that HTML design represents a different skill set than programming.

XSLT can also separate HTML from code, but it does this by embedding it inside of a different kind of code. The editor support is not there. The pool people who know XSLT is tiny compared to the pool of people who know HTML. The learning curve to go from HTML to XSLT is steep. The learning curve to go from HTML to Templates is generally shallow.

Separating presentation involves complexity. If you have divided responsibilities on a web application, you have to ask where should I dump this complexity? On the designer or on the programmer? XSLT dumps it on the designer. Templates (can) dump it on the programmer.

Template engines that resemble programming languages (imperative design) dump that complexity back on the designer.

Would I be wrong in assuming that most of the people arguing in favor of XSLT and imperative features in templates either do not divide responsibilities between different people for programming and design, or are on the programming side and want to push the complexity to the design side?

That said, there IS a place for XSLT and imperative template languages. IT has to do with the degree of separation between the programmer of a product and the designer.

For a one person project, it hardly matters what you do.

For an internal project, where the designer and programmer are part of the same organization, I think the template approach is better. (complexity is dumped on the programmer).

For a commercial product (such as x-cart), where the programmer of the product and the template designer (or customizer) are very different people, something with programming language power like XSLT or an imperative template language makes sense.

If the commercial product has a consumer audience, XSLT looses its appeal. Jane blogger is not going to learn XSLT just so she can make her blog pretty.

Good Points there Selkirk, me personally I think the workload is for the most part dumped right at the programmer’s door, though I would prefer the workload in regards to design and using templates be dumped right at the door of the designer since they have the easy life…

Us programmer’s it’s actually us who have to use our brains, whereas designer’s only need some imagination and a bit of flare so to speak ?

Why should the designer’s get the easy life huh ?

I still can’t clarify your distinction of XSLT as something other than, a markup language, maybe i’m looking blindly into what your implying, but as far as I see it XSLT, is a derivative of XML. Set aside any injunctions with processing/parsing them, at the heart of it, its a template('please correct me’). When you actually come to parse, that template via the many parsers, it provides some limited logic and conditional, capabilities.

Yes, that is essentially the fundamentals for a programming language(PL), but then you could argue that scripting languages are full blown PL’s.

XSLT is a program. (Yes, a program file can be a document in another context, but that misses the point. Read Tim Berners Lee’s Principle of Least Power on why html is not a programming language for clarification of this issue.)

I can understand that, html is not a programming language as it does not embed any conditional arguments, such as XSLT. However, I still think thats rather out of conext as you mentioned. ("When I get a chance I will read [i]Principle of Least Power[/i]." ). Also i’m not refering to XSLT altogether as an templating language. Although it does provide solutions to resolve templating strategies, (“Look at smarty is that a program because it involves logic in the template, which is handled by PHP?”). In a way this could get a bit rhetorical on actually classifying a definition. But in my opinion (IMO), I see a single xslt document as a template. Without added functionality of a parser, there would be no logic, to aid XSLT as well as 'smarty’.

Anyway i’m running short on time, so I look forward to your response.

By creating an interface for the designer, simply pushes towards a inflexible system. But thats my next challenge

[size=1]INSTANT SAXON
Details
Engine Type: XSLT Engine
Vendor: Michael H. Key
Platform: Windows 95, 98, NT, 2000 **
Language: Java
URL: http://users.iclway.co.uk/mhkay/saxon/saxon6.4.1/instant.html
ORACLE XSL
Details
Engine Type: XSLT Engine
Vendor: Oracle
Platform: Java, C, C++ and PL/SQL
URL: http://otn.oracle.com/tech/xml/content.html

SAXON
Details
Engine Type: XSLT Engine
Vendor: Michael H. Key
Platform: Windows 95, 98, NT, 2000 **
Language: Java
URL: http://users.iclway.co.uk/mhkay/saxon/saxon6.4/index.html

SABLOTRON
Details
Engine Type: XSLT Engine
Vendor: Ginger Alliance
Platform: C++, g++, Perl, PHP, Object Pascal, Ruby, Erlang, Tcl, Ada, Python, Linux, Windows NT/2000/XP, Solaris, HP-UX, Irix, FreeBSD, OpenBSD, OpenServer, Open Unix, MacOS X, etc.
URL: http://www.gingerall.com/charlie/ga/xml/p_sab.xml

XALAN
Details
Engine Type: XSLT Engine
Vendor: Apache Software Foundation (ASF)
Platform: ?
Language: Java
URL: http://xml.apache.org/xalan-j/index.html

XERCES
Details
Engine Type: XSLT Engine
Vendor: Apache Software Foundation (ASF)
Platform: Java, C++, COM, Perl
URL: http://xml.apache.org/xerces-j/index.html

XT
Details
Engine Type: XSLT Engine
Vendor: James Clark
Platform: Java, UNIX, Windows
URL: http://www.blnz.com/xt/index.html

XP
Details
Engine Type: XSLT Engine
Vendor: James Clark
Platform: Java
URL: http://www.jclark.com/xml/xp/index.html

UNICORN
Details
Engine Type: XSLT Engine
Vendor: Unicorn Enterprises SA
Platform: C++
URL: http://www.unicorn-enterprises.com/

4XSLT (4Suite)
Details
Engine Type: XSLT Engine
Vendor: FourThought
Platform: C, Python, Windows, UNIX
URL: http://4suite.org/index.xhtml

XML PULL PARSER (XPP)
Details
Engine Type: XSLT Engine
Vendor: Aleksander Slominksi
Platform: Java
URL: http://www.extreme.indiana.edu/xgws/xsoap/xpp/

[/size]

[NOTE]
I drew this up a while ago…
[/NOTE]

XSLT is not a derivative of XML. XSLT is an XML application.

Yes, that is essentially the fundamentals for a programming language(PL), but then you could argue that scripting languages are full blown PL’s.

They are.

By creating an interface for the designer, simply pushes towards a inflexible system.

Thats the whole point of The Principle of Least Power. Sometimes inflexible is good. As [URL=http://www.google.com/search?q=%22with+great+power+comes+great+responsibility%22&ie=UTF-8&oe=UTF-8]Spiderman might say: With great flexibility comes great complexity.

XSLT is used to implement the Transform View pattern.

Here is a data flow diagram for a Transform View via XSLT:

[ Application Data ] ---> [ XML ]  --- (XSLT processor) ---> [ HTML ]
                                            ^
                                           /
                                          /
                                       [ XSLT ]

With an XSLT Transform View you start with an XML data document and the style sheet “injects” html into it to result in the final HTML document.

With Template View you start with an HTML document and the template API “injects” data into it to result in the final HTML document.

            [ Application Data ]
                   \\
                    \\
                     \\
                      v
[ Template ] --- (Template Engine) ---> [ HTML ]

Does that make sense?

Hi All. First post on SitePoint, so I may as well get my feet wet with a dilly.

This is a neat thread (thanks HarryF)–I do find the XSLT discussion is just getting in the way. I wrote about XSLT at the smarty-forum (HERE) and I can sum up by saying that despite the fact that it is a so called W3C standard (the W3C being an industry co-opted comittee that is no longer much relevant) it really doesn’t fit the bill as a programmer’s or designer’s best friend.

I’ve been an adherent of XML since the first release draft in 98 and after many years of plugging, I’m not sure it really does EVERYTHING that it is claimed it can do. For serialization (and soon RPC) I now prefer YAML. For templating I prefer Smarty. For data representation I prefer SQL. There are niches that XML (and thus XSLT) can live, but the syntax burden alone rules it out as human PRODUCABLE content. XSLT in particular, is probably the worst of all possible “standards” that is coming from the W3C (but I like XPath).

Don’t believe the hype: you’ll be learning another W3C template language before your XSLT 2.0 code is fully debugged.

Okay, I just wanted to put my 2 cents in.

A template engine for the web should meet certain criteria. For me, this criteria is the following:

1. Pass the Dreamweaver test. You should be able to design the website AND the template in Dreamweaver. At any time, you should be able to open the template up in Dreamweaver, make changes visually, modify the template if you mad any major changes, and close it with relative ease.

2. Simplicity. The learning curve for the Templating engine should be small. Their are many designers out there, and while some of them can grasp difficult programming methodologies, a lot of them can’t. Just as we programmers might have difficulty grasping the finer points in font selection, we have to assume the same for the designers with regards to logic.

3. Validating. The Template should allow, without any modification, the Template itself to be validated against the W3 validation services.

4. Cacheable. Whether you are talking about PHP as your templating language, XSLT, or simply a Smarty-style templating engine, every time the engine reads the template and parses it, it wastes time. The template engine should cache the template to prevent having to reparse the template every iteration. PHP based template engines are usually already cached by their very nature of being PHP, but Smarty or XSLT templating engines need this.

5. Self-Inspecting. Template engines should be self-aware. If a designer uploads, or otherwise modifies a template so that the template is no longer usable, the template engine should NOT allow this to break the existing, working template.

6. Secure. Template engines, and templates themselves, should be considered insecure, and limited functionality should be in place. Designers and users of the template language are not always trusted members of the staff. Even so-called trusted members of the staff have mean streaks in them. It’s the same everyone at a company logs in with their own password to their computer (or at least should).

7. Flexibility. The template engine should be built with flexibility in mind. Not all templates created will be HTML based. Therefore, the templating language should evolve to suit those needs. Whether this involves changing the syntax of the template language itself, or merely adding additional functionality to suit the need, so be it. The template engine, of course in the realm of this topic, is suited for use on the web, WML, XHTML, and even SVG are all valid, and important things a template language should work with.

Heh, well, it turns out to be seven things I look for in a template engine. I am not promoting any type of template language. I am merely saying, these are the things required (at least, in my mind) of a template language. If it doesn’t suit ALL these requirements, it’s just not up to par.

However, with all these requirements, pretty much everything mentioned previously (all the Marker based template engines, XSLT, etc.) fail one or more of these conditions, I believe.

This isn’t meant to say these template engines are bad. Rather, these are suggested as goals. Things to shoot for.

As far as reinventing the wheel is concerned, I don’t see anything wrong in having 50, 60, or even 100 templating engines/languages out there. So what? How does that hurt us? I guarantee if all those developers got together, it wouldn’t make a difference. Each one developed their template engine for a reason. Whether that reason was to learn how to make one, just for fun, because they couldn’t find features in another one and it was too difficult to modify, or maybe they even thought they could do it better.

People always talk about reinventing the wheel, and I always chuckle when I hear that. Programmers reinvent the wheel all the time. That’s why we have all that we have. What if Linux decided to NOT create Linux because Minix did mostly what he needed. Rather, he decided to put a little effort into fixing Minix so as not to reinvent the wheel. Yeah, I know, it may not entirely be the same thing, but that’s also the point.

These people went looking for a template engine that fit their needs. They didn’t find one, so they made one themself. More power to them. If suddenly they come to find that one that did what they needed it to do existed, so be it. It wasn’t there when they needed it the most.

This was the reasons I ran my boards on phpBB. Invision Board wasn’t launched yet, so I went with what was already there. I have people who as me why I didn’t go with this board or that package. I tell them: phpBB had what I wanted at the time. Nothing else did. It was as simple as that.

Anyways, now I am way off topic, and making no sense.

I see what you mean now. Having said that, I can assure you that you can indeed create enirely different interce systems at the XSL level. I’m not kidding. Even if the entity types for these different interfaces are fundamentally different. I believe that the WML decks vs HTML single pages is an ideal example (see my previous post) of asymetric types. The decks require customised navigation infrastructire that the single HTML doesn’t want. This whole interface subsystem can be encapsulated (completely decoupled) in XSLT - regardless of if transformation is client-side or server-side.

I sincerely hope you are right about the speedy adoption of PHP 5. But since there is no ETA on it, I can’t afford to hold my breath.

Yes, this is indeed an issue as you point out. I do believe it would be an issue for any other system though. Other systems like smarty alleviate this problem by doing some form of caching (including compiled PHP script caching) which is very admirable (really, smarty is quite impressive). But what’s to say that an XSLT user can’t cache transformations or the XML source depending on demand. There are no less than two opportunities here for caching.

Having gained some experience from being on the XSL mailing list, I should point out that XSLT processor performance is also greatly affected by the XSL code itself. For instance, you can create ineficient XPath queries very easily if you are an XSL newbie. Of course this usually only comes into play if your XML datasources become large.

To avoid the complexity of inventing my own XML/XSLT caching subsystem, my production application (which has been quite busy) doesn’t use any caching at all. I think the stylesheets are reasonably efficient, but that are also quite complex in this case. In XSL circles, it is widely accepted that XSLT processors written in C - especially sablotron, are “blazingly fast” (depending on the templates).

Proprietary template system written on top of PHP are interpreted. So they would have to be simpler (less sophistication) to keep up with processors like sablotron.

I’ll conclude by saying that the performance overhead issue is not as simple as all that. There are many factors involved so it is unfair to assert that XSLT usage neccesarily means higher performance overhead than other proprietary templating systems.

You have not convinced me that XSLT template design is not template driven design.

what about WYSIWYG editors like XSLT Designer from Altova?
Are there any editors that will “translate” (interpret) any proprietary PHP template languages allowing the user to design templates in this language with real-time WYSIWYG tracking?

For content management, they provide an active-x control that uses an XSLT template to provide the wysiwyg for the underlying content (which is dandily contrained to your schema).

Thanks Harry for the very complete list of templating engines, and for fostering such an interesting discussion of the pros and cons of various templating approaches (i.e. XSLT vs the world

I’m very keen to see a comprehensive benchmark of these templating engines, or at least the top 10 or 20. I understand it’s a lot of work, but I’m sure if we all muck in, it’ll get done fairly quickly. (Of course, we then have the problem of disparate hardware/software platforms… But you know, some kind of metric is better than none at all.)

Unfortunately, until XSLT adoption is more wide spread, suggesting that designers should abandon tools the currently use to design in another piece of software is not the answer.

Rather, you should promote XSLT adoption in Dreamweaver and GoLive. Luckily, Macromedia seems to be more than willing to work to support standards.

However, even still, there doesn’t exist a good XSLT-PHP Templating engine out there right now (at least, none that I have seen). From everything I have seen, I still have to work to output XML, and then I have to go the extra mile of connecting the XML and the XSLT together.

Also, the XSLT approach fails to meet my 7th criteria, that of Flexibility. XSLT is for converting XML documents to other XML documents. This limits the use of the template engine to XML documents, something that is not suitable.

For me the issue is simple.

It is not a case of “standards for the sake of standards”.

At the end of the day, I want to be able to use various pre-written applications or componenets that are written in PHP. A good example is phpBB or some sort of portal system like PHP Nuke. When I adopt these, I want them to take on the common look & feel of my site or application. Thankfully these apps do indeed use a templating system which allows me to do this.

The problem is that they all use different [proprietary] systems forcing me not only to learn multiple templating languages, but to take a peice-meal approach to integration issues.

Standards are designed to provide relief for those developers (of such applications) who want it. For the end-user/developer like myself, it is easier if they all (or at least most) used the same system.

I don’t think there is much point arguing over which system is better (although, PERSONALLY, I haven’t seen a “better” system than XSLT). I just think it is easier to only have to worry about the one system that the industry supports.

I think people should use whatever they want. As someone mentioned before, people are entitled to re-invent the wheel - I do it myself sometimes. But on the issue of what’s easier for the developer out there?

I think the following quote typifies user/developer sentiment…

KISS

I agree. I am an advocate of sorts for standards when it comes to CSS, XHTML, etc. I like standards in coding, and documentation. When standards are good, they are great.

However, in a case like XSLT, what it was designed for (XML to XML conversions), and what it’s used for (XML to XHTML web designs), things can go wrong. Trying to design a design using XSLT is wrong. It’s just wrong.

100% wrong. Wrong, wrong, wrong. =) I don’t know, just felt like saying it a few times.

That’s what CSS is for. XSLT, for what it was designed for is great. However, out of it’s element, it’s a mess. Of course, that’s just like anything, really.

I’m totally with you on this issue brother, I think many other developers who do want to use XML/XSLT feel the same way (even if there are a couple of systems like Krysalis and Ambivilance already out there). This is what I faced when I first started coding XML/XSLT apps in PHP.

I think developers want simplicity, good cohestion and good decoupling. I intend to personally contribute to making this a reality for XML/XSLT application on the PHP platform.

following is a post which is the contents of my application to sourceforge for the beginning of such a project.

take note of today’s date. This project is going to get wings quickly (provided (and when), I recieve appoval from SF.net).

To put my money (effort) where my mouth is, I am personally gonna take some action to prove what I have been talking about. Below is the application for a new project at sourceforge which I am calling “XML Application Objects: for PHP”.

check it out
++++++++++++++++++++++++++++++++++++++++++++++++++

The XAO class library will be written in PHP. It will require the DOM XML and XSLT extensions. Optionally, it may require the PEAR library and XML-RPC extension. As the libray develops and new functionality is added, other PHP extensions such as CURL may be required.

XAO may be utilised whereever the PHP/webserver platform is available.

Developing robust XML applications in PHP using XSLT requires signifigant effort when writing applications from scratch. XAO takes out much of the mundane work required to perform the tasks associated with XML content aggregation and payload transformation (XSLT). It also provides a point of collaboration for developers to solidify and stabalise these basic functions. The design of the library itself is intended to foster free-form object oriented design and therefore takes a lightwieght approach to the API. The library itself may be used as a framework (framework mode) or simply as functional entities. While designed to be inherited, the classes may also by simply bound by association instead. Flexibility, choice, and low-impact are the drivers behind the design.

Challenges:

• obstacle include PHPs limited error management.
• path resolution issues for XSLT processors (ie. XSL import directives)
• routing trapped exceptions
• thread safety for flat file XML datasources
• the changing nature of the DOM XML extension for PHP

Specifically, the library will provide the following core functionality:

• CONTENT AGGREGATION framework (the basis of XAO in framework mode)
• Safer, simpler, more ubiquitous DOM XML document instatiation (and in some cases, thread safety for XML flat files)
• DOM XML document API accelerators (simplified DOM API helpers for content creation and searching)
• XML content debugging
• XSLT transformation debugging
• Graceful XML based exception handling (where possible)
• User Agenet evaluation API (used for client-side transformations)
• Tabular data (RDBMS query results) to XML conversion and structural mutation via user-defined call-back methods [available only in interpreted languages] (aggregation module)
• Pure XML database access for Xindice (aggregation module)
• Simplified SOAP/XML-RPC (remote aggregation module).
• Asyncronous messaging client - ie. Jabbber (aggregation module).

As a matter of fact, it is possible to slap together an application for displaying XML content without writing any of your own classes.

The primary protocols and formats will all be XML based - except where converting an external content source to XML for use in XAO. As such the list of data encapsulation schemas is open ended. ie. SOAP/XML-RPC, RSS, DocBook, Jabber. At the core is XSL and the DOM API.

The startup source code for this project is based on work I’ve used in production applications for the past 9 months. While it is only the beginning, I have enough experience to know exactly what direction needs to be taken. As yet, there is no dedicated web page hosting the source (hence my SF application). I will use my personal web site to host tutorials and examples of implementation if SF does not have PHP(4.2.x+)/DOM/XSLT facilities.

tezza: Good show!

In designing this, I think you should also look to other template engines, and see what makes them popular. There are reasons they are popular, and it’s not just because XSLT has a higher learning curve.

In developing a library, I spend time working on the interface to the library (note: I am sure you are well aware of this, I am just including it here to sound important =)). I write up code, actual PHP code (or whatever) that is a sample of how I would use the library of code I am writing. That way, when I go in to design the library, I have a clear understanding of what the end result needs to be.

Sometimes this can be difficult. I have an interface that is just difficult to develop. Usually this means one of two things: either (1) that the interface was poorly designed from the beginning, or (2) I just need to work harder.

XSLT is not alone remember - there’s also CSS which (apparently) is a form of XSLT. The two together may provide a clue - the active word being “styling”. Perhaps we should talk about “styling” vs. “templating”

The test may be (just fishing) is to ask “is it a reversable operation”?

In other words, given the end product (e.g. output html) and the “rules” (e.g. a XSL document or a template parser) that were used to get there, can you get back to the starting document? With XSLT I’m pretty sure you can but I’m also fairly sure that parsing a template is a one way operation.

Based on my own experience, I can sympathise with you. Believe me!

XSLT is not a mdium for DESIGN.

My advice is to do your generic design in whatever design tool you’re used to (ie. dreamweaver), then decompose it into templates. Then you can cut/paste these into an XSL stylsheet. This concept is not new, for many years people have done just this with PHP, ASP, ColdFusion. They do all their creative work in DW, then make a PHP page out of it, putting code where the dynamic bits go. You can do this and a great deal more with XSLT.

Also, check out XSLT designer from altova.
(no, I do not work for altova).

It’s unfortunate that XSLT has the word “style” in it when it clearly has nothing to do with styling. This might explain some of people’s misconceptions about it’s usage.

A can answer this.

If you KEEP all the content of the original source XML when creating output XML, then yes, the processes is reversable - providing you also have enough information to create the original relationships.

If you use the <output/> directive to create output that is NOT well formed (XML based) - such as HTML, then it is not reversable. It is worth noting that XHTML was designed to be well-formed so there is no reason not to output a well-formed result tree unless you are creating a CSV file or something.