I have an XML-based web site. I have a collection of
stylesheets which convert my Web site's internal XML data
into various client-customized-HTML. For example, for my
premier clients I have a stylesheet which applies a 5%
discount. For clients with handicaps I have another
stylesheet which displays a select product list. For
international clients I have still another stylesheet which
converts prices to the appropriate currency.
Lovely example of the American use of "international" to mean
"foreign"...
And so forth.
Further, as a relationship is developed with a new type of
client I simply drop in a new stylesheet. The new client is
thus seamlessly integrated.
Is this a good use of XSLT? I don't think so. The problem
is that I am dispersing my business rules across the
stylesheets, e.g., premier clients get a 5% discount.
Maintaining such a system becomes a nightmare.
I have seen excellent examples of applications which used XSLT for this
kind of calculation. But they did not disperse the business rules across
the stylesheets: they were centralized in a single place (actually a
meta-stylesheet), and the data driving the rules (e.g. the mapping of
customer categories to discounts) was held as "business parameters" in
separate XML documents.
Of course you can write badly-structured code in XSLT, just as you can
in other languages. The language that seems to encourage really bad
practice in this respect is ASP. But you can also write good code in any
language.
Michael Kay
Software AG
home: Michael(_dot_)H(_dot_)Kay(_at_)ntlworld(_dot_)com
work: Michael(_dot_)Kay(_at_)softwareag(_dot_)com
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list