cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@STJUDE.ORG>
Subject RE: Design of unmarshaling sitemap component
Date Fri, 30 Jul 2004 14:34:34 GMT
DURDINA Michal <Michal.Durdina@assetsoft.sk> writes:
> > 
> > DURDINA Michal <Michal.Durdina@assetsoft.sk> writes:
> > 
> > > Hi,
> > > I would like to discuss the design problem of the sitemap
> > > component. My plan is to develop special let's call it 
> > > transformer for transforming sources for pages written or 
> > > generated by analysts (model) to dynamic pages generating 
> > > required results (implementation). The form of model is 
> > > custom XML according to given XMLSchema and the 
> > > implementation pages should be in form of jxtemplates (or xsp).
> > > 
> > > The transformation should go like this:
> > > 
> > > pipeline:
> > >             additional data
> > >                    |
> > > modelXML -> populated modelXML -> computed model ->
> > jxtemplate source
> > > 
> > > The intent of the pipeline is to generate executable source
> > > from model that will generate required dynamic page. The 
> > > trick is that the computed modelXML is not trivial and should 
> > > be implemented as Java OM. 
> > 
> > Wow.  You're overall requirements sounds a lot like ours so I'm 
> > interested in how you reached this design?  Given your use of 
> > jxtemplate I can't see that it's performance driven? If 
> not, why not 
> > just keep everything in XML from end to end and use XSLT to 
> derive the 
> > computed model?
> > 
> > <snip>Castor/java implementation issues</snip>
> > 
> 
> Yes, keeping everything in XML and using XSLT would also 
> realize the transformation. Given that it would involve a XSL 
> stylesheet that will do all the computations. Such a 
> stylesheet would not be easy to write and it will be probably 
> too complex to maintain. Using Java for computation on input 
> XML should be more straightforward and using jxtemplate for 
> outputing the resulting XML gains from clear view how the 
> resulting XML will look like. Performance was not the main 
> requirement as the source generation occures only once and 
> then it is cached although this should perform better than XSLT.

Hmm, sounds to me like what you're really saying is that you've got good
Java skills around and not a lot of good XSLT skills?  Using a good
tools (like Stylus) I find XSLT in some ways a lot easier than Java. If
you're main goal is data transformation of any kind I believe the XSLT
will be easier to write and maintain than the Java, if you've got the
proper skill sets.

If you've got the kind of mind set that can be bent round XSLT then I'd
say it's worth learning for this kind of thing, you may be pleasantly
surprised.  However, it's certainly not everybody's cup of tea...

> I already started the implementation and have first version 
> of such a component implemented as a transformer (case A.). I 
> hope it will meet my requirements and we will profit form 
> this kind of concept.
 


Mime
View raw message