Re: [xsl] hard problem

[Richard Light <richard@xxxxxxxxxxxxxxxxx>]

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.

Richard

> Even deploying SAXON as a servlet will let you do something like a GET
> URL
> http://www.example.com?xml=somexmlfile.xml&xslt=somexsltfile.xslt
> 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:  http://www.mulberrytech.com/xsl/xsl-list

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


XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list