RE: Application Design

[Leigh Dodds <ldodds@ingenta.com>]

-----Original Message-----
From: Alaric Snell [mailto:alaric@alaric-snell.com]
Sent: 13 August 2001 16:23
To: The Deviants
Subject: RE: Application Design

> And the whole problem of the input XML document - in a Web
> application, the designers are always changing their minds about what to
put on what
> page. With my templating system approach (that HAS no initial document,
> just functions that return values on demand) they get to choose what data
they
> want, rather than having to ask the guy who writes the code that generates
the
> XML data to change what data are there before the designers can update
their
> XSLT to display said data.

To provide some comments on the other side of this debate, I've
been involved in the production of several websites that include
different mixes of XML/Java/JSP/XSLT. And out of all of them
my favoured combination is XML/XSLT + Java. Personally I can't
stand JSP even with plenty of custom tags.

We've found that XML/XSLT works very well - mainly because we're
not using it for bizarre things like calculating standard deviations,
or complex text processing. Why someone would do this I don't know.
However for managing the split between web developer and application
developer I think XSLT is unparalleled.

The web tier of an application is actually two distinct layers: the display
formatting (XHTML, under control over designer), the data produced from
processing the request (XML, under 'control' of the developer).
The contract between them being the XML tags that the designer
places in the XHTML to add specific content [1]. The developer produces
appropriate XML output in place of those tags.

Alaric's argument is that the input document to the transform needs to
be continually altered everytime the designer wants more data. This is
probably correct if you assume a naive processing model where all XML
data is delivered for all pages. However just like PHP can pull in data
as required, one can construct an XSLT based framework that does
the same. Just pre-process the designers template and construct the
input document according to the content they require.

Much more efficient, and very flexible.

I personally think that XSP [2] is one very good way to achieve this
flexibility.

However my main point is that there's nothing implicit in the use
of XSLT that requires the a push (i.e. we must know the exact
input document configuration in advance) versus a pull (i.e. let
the designer request what they need) architecture. These are
separate issues.

[1]. http://www.xml.com/pub/a/2000/07/26/xslt/xsltstyle.html
[2]. http://xml.apache.org/cocoon/wd-xsp.html