Re: [xsl] hard problem

Subject: Re: [xsl] hard problem
From: Richard Light <richard@xxxxxxxxxxxxxxxxx>
Date: Sun, 1 Feb 2004 22:00:32 +0000
In message <000001c3e8f7$9575b030$75827ad5@mustang>, Jim Fuller <jim.fuller@xxxxxxxxxxxxxx> writes

[answer below]

I have a web application which fetches museum records from a
database as
XML and styles them on the fly.  For an initial overview of
hits, I want
to render a set of these records as a summary list with
clickable links
to each record.  When the client clicks on one of these
links, I want to
display one of these records in detail.  Exactly the same XML, two
different renderings.  At present I am having to use "modes"
to achieve
the desired effect, and I'm not even thinking about other different
renderings that users might quite reasonably ask for.  This extension
function would be just the ticket.

Hello Richard,

This is exactly what modes are useful for, though posting an example of
your xml/xslt would be better to suggest something more concrete.

I think that you are starting to use xslt in the hazy gap between
language and framework, and xslt is just a language that's good for
transforming one form of xml into another....perhaps you would be better
served by setting your XSLT processing within a larger framework; and
continue to let XSLT do what its good at, and allow something else to be
Controller of the transformation.

Possibly, though that would complicate what is currently a fairly clean design. Essentially a single XML document encapsulates the complete site, and a single XSLT transformation generates any required page.

The only trickery involved is passing the HTTP request parameters (i.e. state information) to the process. I do this within an ASP by updating the DOM representing the source document before styling it: other approaches, including Cocoon, would do as well.

Initially I had a bunch of JScript within my ASP which dealt with subsidiary calls for XML data from the database. This had the advantage that I could also apply a subsidiary XSLT transformation to the XML and return the transformed result: exactly the functionality we are discussing here. It had the disadvantage that subsidiary HTTP requests don't work under all IIS/Windows combinations - and anyway, I feel in my bones that doing it all within XSLT is much more hygienic.


Even deploying SAXON as a servlet will let you do something like a GET
Though I have not done this, though I have worked quite a bit with
Cocoon, AxKit with great effect. Though I would suspect that even server
side MSXML could be set up to provide a bit more abstraction, instead of
trying to force xslt to do it all.

Gl, Jim Fuller

XSL-List info and archive:

-- Richard Light SGML/XML and Museum Information Consultancy richard@xxxxxxxxxxxxxxxxx

XSL-List info and archive:

Current Thread