Michael Kay mentioned, tongue in check: "Lovely example of the American use
of "international" to mean
"foreign"..."
But, to be serious, treating US presentation different from non-US
presentation is wrong. Your application will be better architected if you
treat all countries the same. The fact that your company reports internally
in US$ just means that the US presentation will have a 1:1 conversion ratio.
I can't count how many times the concept of building a global system from
the start rather than retrofitting "foreign" support onto a single country
system has paid off in the last seven years where I work. (Seven years ago
is when my US based employer merged with a Sweden based company.)
Steve
-----Original Message-----
From: Michael Kay [mailto:michael(_dot_)h(_dot_)kay(_at_)ntlworld(_dot_)com]
Sent: Monday, October 28, 2002 4:12 AM
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: RE: [xsl] Role of XSLT?
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
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list