article::TemplatingSystems

discuss this article

Proprietary template systems
versus the standard - XSLT

Misinformation

There seems to be a great deal of misinformation and mostly lack of appreciation for XSLT. The was some guy on comp.lang.php who was crying about it because "you need to prepend everything with xsl: and that's just a pain" (I didn't even justify it with a response). Obviously this guy has no clue that the "xsl" prefix is a convention and can easily be changed by modifying the namespace declaration. While you don't exactly expect everyone to know this, you wouldn't expect them to make authorotative assertions about technologies they obviously know very little about. There were other people making equally inaccurate assertions about using XSLT. This demonstrates a fundamental lack of understanding amongst web developers in general. It seems that too many web developers are too tired to keep up with standards. Yet they spend precious energy learning a new templating system which may only be transient at best.

How much effort do you want to put in?

I chose XSLT as my templating solution because I am fundamentally lazy. I only want to learn one type of templating system where I can build up a library of templates and use them across a broad range of projects - including ones that aren't done in PHP.

I remember developing websites in the mid to late 90s and experiencing first hand the problems that modern standards have worked to overcome. WHY GO BACK?

At the time, myself and many other web designers/developers struggled with different user-agents causing us more work (having to maintain different versions of highly functional sites for different browsers). It was a standards implementation problem. Since then, standards have evolved and adapted to become immune non-standards based clients (in our client/server environment)(1). All template developers are doing now is moving the problem onto the backend.

The old way vs the new way

I USED to use PHP for it's templating capability (ie. I could mix literal HTML markup with <?php ... ?> functional bits. Other technologies sprang up using the same principle to gain success - most noteably Cold Fusion, ASP, and more recently, JSP. However, as my PHP skills have improved, my appreciation for PHP as a purely useful scripting language has deepened. It's ability to parse templates is much less important to me. Now I use it for it's "out-of-the-box" high degree of functionality. I can even organise my code in an object oriented manner without the overhead of dealing with a [so called] fully-blown object oriented technology such as Java or C++. I'm going to conclude this paragraph by stating categorically that templating methodologies that formed the basis of PHP, JSP, ASP are obsolete - they are now the "wrong" way to go.(2)

I must stress though that this is a recent phenomenon due entirely to the *maturity* of XML and surrounding standards. No matter how good your proprietary template system is, it's not much use to me as a developer. As a developer, I only want to learn one templating system and I want to learn it well! I also want this templating system to have enough depth so that given enough knowledge, I can achieve almost anything with it. And since the XSLT specification is driven by a significant standards body, it will constantly be improved for the forseeable future.

The best of the bad

Getting down to the individual aspects. First let me say that the article at http://wact.sourceforge.net/index.php/TemplateView is very well worth the read. The author has obviously done a bit of research and it shows. Eventually he goes on to explain why his particularly templating solution is so good (using markers). This markers approach is briefly touched on by Harry in http://www.phppatterns.com/index.ph...icleview/8/1/2/ . But by Harry's own acknowledgement, this method is tightly coupled(3) between the domain of display and the domain of content aggregation due to the fact that it's the backend programmer who has to provide all the new widgets. I don't care how good the rest of it is, this alone is a fatal flaw. By contrast, XSLT fully (and I *do* mean 100%) separates the job of producing the content from the job of arranging the output (in our case, usually HTML markup). XSLT Designers can easily create their own widgets using templates (named or otherwise). Furthermore, they can continue to use those widgets on their .NET or their JSF (Java Server Faces) applications. I'm not even gonna get into the benefits of hiving off the transform work onto the client (I avoid this due to the old "standard implementation" problem).

XSLT has a lot of depth, the learning curve can be steep

Then there is the issue of pumping mental energy into learning XSLT. Make no mistake, XSLT can be difficult. Sure, it's easy to do your basic hello world stuff but once you start dealing with real-world problems, you have to stoke the fires for your brain to keep up sometimes. But as I have experienced, with practice, life becomes very easy for XSLT design. I think one of the reasons it was difficult for me personally was because as a PHP programmer, I'm too used to imperative programming. Learning to write templates declaratively was half the battle. It's just different. I had to get over this different way of thinking which was tough for me. Part of the problem with attacking XSLT design with an imperative approach is that you try to use XSLT's imperative "bits", like the built in functions, too much. After some practice, you will get better at separating the display logic out from the content logic and you rely less on things like XSLT's inbuilt functions. It's the same story with the other imperative bits of the XSLT language such as <if/>, and <choose/>. At first these are awkward but you learn to use them less - not because they are a pain, but because functionally, your problem is better solved by taking advantage of the declarative nature of the language. Another problem I had trouble getting my head around was variable (or parameter) scope, again, I was approaching the output declaration wrongly. Getting this right takes time and is hard for me to explain. Obviously for me, the investment of my energy into learning XSLT has been well worth the effort. Now I can use my XSLT skills on other technology platforms including Java, .NET, C++ or Python - to name a few.

What about graphic designers? If it's hard for seasoned programmers, what hope do they have?

Firstly, graphic designers don't have the problem of having to force themselves to stop thinking imperatively. So the declarative nature of XSLT is actually more natural for them to pick up. You'd be surprised how quickly some graphic designers can learn XSLT.

Secondly, because XSLT is a standard, there will be more and more software like Altova's XSLT designer which will allow WYSIWYG template development.

why ignore XSLT

I can speculate on a number of reasons why good PHP developers are still ignoring the XML/XSLT combination despite it's maturity.

1. It's different. XSLT is different, it uses declarative thinking, not imperative thinking.
2. FUD - there is a lot of misinformation being peddled by people who have only meddled.
3. There are more non-standards template solutions for PHP than there are standards (XML/XSLT) based solutions. I think this is more for reasons of legacy since PHP has been around since before XML.

My recommendation for developing modern websites:

1. Come up with a vocabulary that encapsulates what you are trying to say - an XML schema. This can be can be informal, you don't have to learn schema definitions, just decide what tags/attributes (and their general relationships) you will use as a minimum. This can be an on-going thing, don't worry if you've left something out for later. I'm no XML schema expert [yet] and I can successfully build functional applications in XML.
2. Work out which objects (roles and responsibilities) you will need (DON'T use functional decomposition). Then build XML accessor methods on the appropriate classes so they can provide their content using your XML vocabulary.
3. Build some XSLT templates which will provide suitable output for your needs. Better still, get your interface designer to build them, notifying them of your XML vocabulary/structure.
4. Find a framework (like XAO) or work out some other convenient way to perform the transformation on demand.

This is only the beginning, but it's enough for most basic applications. Solutions can really scale from here.

discuss this article

XAO features relating to this article

• XAO completely removes the complexity of XSLT processor implementation. You can spend quality time developing the GUI (your XSL) rather than learning the intricacies of the processor.
• XAO has extensive debugging facilities including display dumps of XML/XSL source snippets with error lines highlighted. Maximum error detail is extracted from the processor/parser.
• XAO hides the procedural API (native to PHP) in an object oriented architecture.
• XAO Encourages and guides developers towards complete and utter separation of content logic from display logic, providing solutions to all the associated challenges.
• Is not over-prescriptive as far as framework restrictions go - ie. using an MVC pattern is entirely optional. Use XAO as a library or in framwork mode - the choice is yours. The one strict prescription is OO over procedural architecture.
• Custom Tags: XAO allows you to nominate tags which can be processed by call-back methods. Nomination can be by name or by XPath query. This functionality is NOT intended to function as a display logic engine.
• To maximise performance options, XAO will provide at least 2 points in the application data pipeline where dynamic data can be cached - source XML and XSLT result. More on this in the near future.
• XAO is extremely forcused on knowledge support. It achieves this through an excellent documentation programme, and awareness articles such as this one. As popularity increases, community development will become on of the primary sources of knowledge support.

recommended books:

• "XSLT 2nd Edition: programmers reference" (Michael Kay). Don't try to read this, just use it as a reference - trust me.
• "XSLT and XPath: On the edge" (Jeni Tennison). This is more like a cookbook, but more than a cookbook.

If you join the XSL mailing list at http://www.mulberrytech.com/xsl/xsl-list you will find that both of these authors are fairly active on there. The sort of support provided there would be worth heaps commercially - couldn't ask for better!

If you're a newbie and want to learn XSLT, I recomend using the web. Sites like http://www.zvon.org/ and http://www.w3schools.com/ are good places to start.

footnotes:

(1) I am NOT talking about HTML or even XHTML!

(2) Clearly, I am refering to their usage as TEMPLATES, not to their usage in general. I plan on porting a library from PHP to Java using JSP as entry points to the application the same way .php pages provide entry points to most PHP apps.

(3) Tight coupling is bad(tm). Tight cohesion is good. Loose coupling is good. So from a design pattern point of view, proprietary marker based templating solutions (while better than most) are *still* bad. See the Addison and Wesley "Design Patterns Explained: A New Perspective on Object Oriented Design" book by Alan Shalloway and James R. Trott on page 8 (yup, right at the beginning of the book).

(4) Mostly PHP's terrible error handling was to blame here. This aspect alone makes it difficult to handle exceptions in an XML context.

(5) The library that I am developing is not yet fit for release (aside from the fact that PHP might/will change the behaviours of the DOM XML extension). I need to re-factor the design and do some more testing. I've developed the library in my own spare time on a test project (pure XML photo album software with no need for an RDBMS). It is not a framework because it does not call the developer's scripts. Using a controller(MVC) is up to the developer - centralisation is achieved through inheritance. I think I'll ask around here for opinions on whether or not I should submit it for inclusion in PEAR. I actually came up with a light-weight MVC controller which I used in the application successfully but it was entirely procedural so the design was limited. It was always my intention to move to a 100% OO solution.

(6) No, it's not using the XSLT functionality from the DOM XML extension. As I mentioned in a previous post, this would be a really bad idea.