This article is basically an edited version of a
discussion forum. It's a significant post in that it is part of the
inspiration for me to get off my bum and dive head-first into
working on this project.
discuss this article
Proprietary template systems
versus the standard - XSLT
I posted this article to a discussion forum after becoming frustrated
at the number of times I ran into people saying that XSLT was "crap"
and their proprietary templating system was "much better"TM.
Often times these people demonstrated that they hadn't a clue about XSLT
and obviously had never even tried writing a template themselves.
This thread came about due to someone trying to compile a list of all
the [proprietary] templating systems in existence for PHP. I think at last
count it was up to something ridiculous like 75! Now I'm
not against re-inventing the wheel per se. Sometimes it can surely be
beneficial, but the sheer number of projects dedicated to their own
"much better"TM templating system begs the question -
What's wrong with the standard solution?
[to the templating problem]
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
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
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
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.
- It's different. XSLT is different, it uses declarative thinking, not imperative thinking.
- FUD - there is a lot of misinformation being peddled by people who have only meddled.
- 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:
- 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.
- 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
- 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.
- 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.
-- Terence Kearns
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
- 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
- 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.
- "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/
are good places to start.
(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