cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maddison, David" <Maddis...@dnb.com>
Subject RE: [Cocoon Devel] RE: Dynamic XSL
Date Fri, 01 Sep 2000 14:21:49 GMT
The way I see it working, is that each object would add it's formatting,
(based on the client and presentation model, (i.e. HTML, WAP, PDF), to the
XSL.  That way, the complete layout isn't know until runtime, i.e. I can
change the format of a module in WAP and the page doesn't have to know.

For example, suppose I had a PressRelease object, I may have different views
on this data, i.e. SUMMARY giving a quick overview for a list, and FULL
giving the full article.  The PressRelease object would add it's data to the
XML document, for example :

<PressRelease>
	<Title>Cocoon 2 Released</Title>
	<Summary>
		The Apache Foundation anounced today the releaes of Cocoon
2.
	</Summary>
	<Full>
		Today saw the announcement by the Apache Foundation, of
Cocoon 2, the worlds most advanced 		XML publishing engine.
	</Full>
</PressRelease>

Now on my first page, I may want the summary displayed, however this is also
dependent on the model, for example it's going to be displayed differently
on a WAP browser as an HTML browser.  Therefore the formatting could be
picked up from a file named (using a pattern),  HTMLSummaryPressRelease, or
WAPSummaryPressRelease, these two files being the part that the designer
works on, independent of the logic programmer.

I could also display the full press release simply by adding the
HTMLFullPressRelease file to the XSL, instead of HTMLSummaryPressRelease.

My design, (on paper and a quick RI so far), uses the concept of 'publish
objects' to bind an object to it's representation.  A publishing Object
contains the ID of a 'ContentObject', (similar to an EJB entity bean), and a
display method.  A page object then contains a collection of publishing
objects, which get invoked at run time.  The publishing object then calls
the .toXMLString method on the content object, (which tells the object to
render it's data as XML), adding it to the XMLDocument.  At the same time
the publishing object also adds the correct formatting file, (i.e.
HTMLSummaryPressRelease), to the XSL file.

Eventually at the top of the tree, the XML & XSL files are complete and
pushed through the reactor, and if all goes correctly, the resulting
document is spat out!

Tell me to shut up if this doesn't make sense!

David Maddison

-----Original Message-----
From: Steve Allman [mailto:Steve.Allman@vcint.com]
Sent: 01 September 2000 10:39
To: 'cocoon-dev@xml.apache.org'
Subject: RE: [Cocoon Devel] RE: Dynamic XSL


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 [SMTP:MaddisonD@dnb.com]
> Sent:	01 September 2000 10:44
> To:	cocoon-dev@xml.apache.org
> Subject:	[Cocoon Devel] RE: Dynamic XSL
> 
> This sounds really good, where can I get more hardcore information on
> XSLT,
> 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 [mailto:simon@viafone.com]
> Sent: 30 August 2000 20:43
> To: cocoon-dev@xml.apache.org
> 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
> XSLT
> 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 [mailto:MaddisonD@dnb.com]
> Sent: Wednesday, August 30, 2000 2:57 AM
> To: cocoon-dev@xml.apache.org
> 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 : davmad@jabber.org
> 
> 
> 
> _______________________________________________
> cocoon-devel mailing list
> cocoon-devel@lists.real-time.com
> https://mailman.real-time.com/mailman/listinfo/cocoon-devel


Mime
View raw message