cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Allman <>
Subject RE: [Cocoon Devel] RE: Dynamic XSL
Date Fri, 01 Sep 2000 09:38:55 GMT
I am working on a project to develop complex statistical/market research
questionnaires, with all the structure, presentation and supporting metadata
held in a repository. The structure and presentation would be represented by
an object model and developed by designer tools. Questionnaires could then
be published to the web, paper and possibly WAP via Cocoon.  The challenge
here is to produce XSL to drive the presentation layer. To do this via
parameterised XSL seems non-evident to me - you would have to know pretty
much in advance what questionnaires the user would design. It would also be
a complex transformation from the object model to generate the required
parameterisation. The only cleanly archeticted solution would seem to be to
generate XSL from a presentation object graph. This would need to be done
via a Producer. XSL would never be edited directly, it would all be
generated according to an object model.

Any thoughts ?

Steve Allman

> -----Original Message-----
> From:	Maddison, David []
> Sent:	01 September 2000 10:44
> To:
> Subject:	[Cocoon Devel] RE: Dynamic XSL
> This sounds really good, where can I get more hardcore information on
> all the books I've picked up so far only 'skim' XSLT as part of an XML
> technology, however after playing with it, I can't believe how powerfull
> it
> is!
> The reason I think I need XSL is because in my publishing system the style
> sheet is built up using different objects.  For example the page object
> gets
> called, which adds it's data to the XML document and then it's formatting
> to
> the XSL.  The page object then has a list of all the objects on the page,
> each one has it's chance to add it's data and then it's XSL formatting,
> and
> so on down the tree until all the data, and all the XSL processing
> instructions have been fetch.  They are then put through the reactor,
> generating the final document.
> The thing is all the objects are added to pages dynamically, so for
> example,
> there may be a Module object on the page, there may not.  In order to do
> as
> you suggest, and use parameters, I would have to have a stylesheet that
> contained ALL the object formattings, which would be a bit of a pain in
> the
> butt, both to administer and code, as well as slowing down the XSLT
> processor.
> On certain sheets I also have objects placed in certain positions within
> the
> page template.  The objects are chosen based on an ID attribute, for
> example
> there could be 3 Module objects on the page, each containing different
> contents, however they each have a unique ID attribute.  I then tell the
> XSLT processor where to place the Modules using the following syntax :
> <xsl:template match="/">	
> 	<table width="100%">
> 		<tr>
> 			<td valign="top">
> 				<xsl:apply-templates
> select="Module[@ID='1']"/>
> 			</td>
> 			<td valign="top">
> 				<xsl:apply-templates
> select="Module[@ID='2']"/>
> 				<xsl:apply-templates
> select="Module[@ID='3']"/>
> 			</td>
> 		</tr>
> 	</table>	
> </xsl:template>
> Maybe all this CAN be done with parameters, and I just need to read a good
> book.  On a thinking note, could XSL get it's parameters from the XML
> document?  If so that might put a completly different spin on things, as
> the
> required object formatting could be dynamically Imported?
> Certainly interested in the new design documents for Cocoon if anybody has
> them, (ie the pipeline approach), it may save me replicating work!
> David Maddison
> -----Original Message-----
> From: Simon Waddington []
> Sent: 30 August 2000 20:43
> To:
> Subject: RE: Dynamic XSL
> I have a feeling you haven't explored the capabilities of XSLT far enough.
> You can do some extremely complicated stuff with it and it is easy to
> modify
> the XSLTProcessor to pass in environment as style sheet parameters.  Or
> you
> could dynamically generate a stylesheet fragment consisting of parameter
> declarations that is included into a main stylesheet.   The main
> stylesheet
> then modifies its behaviour based on the parameters, just as any other
> piece
> of code would.
> I have yet to think of a problem complicated enough to require dynamic
> generation of XSLT that couldn't be solved with parameterized stylesheet
> behaviour.  But I do see the need to execute code before the stylesheet is
> processed to determine what those parameters should be - that's exactly
> what
> XSP and the processor pipeline is for.  Heck you can even pass date to
> without modifying the processor at all - just get some XSP to add extra
> top
> level nodes (PI or otherwise) containing styling info into the output
> tree.
> Your XSLT then reads these and modifies its behaviour accordingly.
> -----Original Message-----
> From: Maddison, David []
> Sent: Wednesday, August 30, 2000 2:57 AM
> To:
> Subject: Dynamic XSL
> Cocoon is cool, especially as a proof of concept, definitely proves that
> XSL/XML based publishing systems can work fast enough, even faster than
> some
> 'old world' systems I know.
> Although the cocoon framework allows me to hook in my own producer, (which
> is cool!), it doesn't allow me to hook in my own XSL producer, which is
> something required for a true publishing system.
> Why would you need this?  Well consider a users home page, similar to My
> Yahoo.  The user can decided on an indivdual layout, but the data behind
> is
> exactly the same, so in this case I want the data to be created, however I
> want the ability to dynamically create the XSL for layout, based on a
> users
> preferences.
> A full web system, (similar to Allaire Spectra or Vignette), is something
> I'm speccy out at the moment.  It'll problably use Cocoon as the
> publishing
> engine, (with my own producers, etc), but provide all the other things
> Cocoon doesn't, i.e. User profiling, Content Objects, Role based security
> etc.
> Would also be cool if the producers etc could be 'Bean'effied' that way
> the
> engine could be distributed over several EJB servers!  I'm thinking maybe
> the request could  be split into two threads, one that goes and gets the
> formatting, and one that goes and gets the data, both merging to produce
> the
> final result.
> David Maddison
> Yahoo IM : maddisondavid
> Jabber IM :
> _______________________________________________
> cocoon-devel mailing list

View raw message