cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira>
Subject Re: Custom Generator or Logicsheet (or something else)?
Date Thu, 16 Oct 2003 14:50:40 GMT
Patrick Dobbs wrote:

>I'm working with a standard Java webapp. The business logic is in a
>library of around 300 standard Java classes. There is a management site
>written in JSP. For each customer implementation we then code custom
>pages for our customer's public users (with taglibs). However, we want
>to switch to Cocoon. The plan is to create a high level API in Cocoon to
>make it easier to put together these customised pages by just tweaking
>some XSLTs and juggling sitemap components. 
>My question is what the best approach to take is. Current ideas include:
>1) Logicsheet. Create a custom logicsheet which wraps calls to the
>existing class library. Then write generators in XSP. 
>2) Custom Generators. Code generator(s) which will accept sitemap
>parameters for filtering what data is needed. 
>3) Aggregate. Pull in our application data further down the pipeline
>Logicsheets seem more flexible, but I'm aware that the API will become
>very extensive over time, and I'm not sure if this approach will scale.
>The concern with aggregating is performance.
>Is there a better approach I've missed?
It depends upon exactly how your site is going to work - whether it is 
just presentation, or whether you want to manage the flow between pages 
on the basis of results of your java classes. I would suggest either of:

1) If your site is presentation only - a custom generator that accesses 
your business logic and passes out SAX events
2) If your site needs to manage flow between pages - use flowscript to 
invoke your business logic, and then hand javabeans back to the pipeline 
for rendering, using jxtemplategenerator to read data out of the bean to 
be placed into the pipeline for presentation.

These seem to me to be the two best approaches. I would find 2) the most 
enjoyable/satisfying, but that's not always the best way to judge these 

Regards, Upayavira

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message