cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Noels <stev...@outerthought.org>
Subject Re: [RT] Generalizing the flow
Date Fri, 04 Jul 2003 20:32:32 GMT
On 4/07/2003 20:20 Christopher Oliver wrote:

> What exactly is "Marc's case"? I read his wiki and I have to admit I 
> don't understand what he's talking about.

He'll get to answering this himself in due time, but a sample is the 
project we are currently working on: a large EJB app that drives not 
only business logic, but also the different screens/forms one needs to 
go through to trigger actions. The forms are *heavily* personalized, in 
the sense that they are both complex, and that the flow connecting them 
depends on backend logic.

It gets even more interesting since the backend app itself is basically 
configured using a (meta)data repository, which not only contains the 
data models (and i18n stuff and all that), but also the flow or paths 
(very Xpath-like) connecting model properties. The customer even wants 
the Woody form definitions to be generated from that repository, either 
statically or dynamically.

But that's quickly of the top of my head - Marc will sure have lots of 
corrections. I'm pretty sure though that a similar setup exits in many 
serious applications. Cocoon isn't always driving the application flow.

In xReporter, all flow is also being handled on the backend, and 
communicated to the Cocoon frontend, see 
http://xreporter.cocoondev.org/en/overview.html#Technical+Architecture 
and http://xreporter.cocoondev.org/en/httpinterface.html. The Cocoon 
sitemap is explained in 
http://xreporter.cocoondev.org/en/cocoon.html#Pipeline+structure

HTH!

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at            http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org                stevenn at apache.org


Mime
View raw message