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
