cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: [RT] Generalizing the flow
Date Fri, 04 Jul 2003 22:03:44 GMT


Steven Noels wrote:
> 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.
> 
> 

Steven used a lot less words to precisely describe...
In general think about a backend doing the workflow control: then 
you just need some gateway logic... (in the wikipage there is 2 
or 3 more examples in the stateless section)

All in all, I don't think 'that' case is all that important, the 
attempt was to 'generalize' the flow outside that case as well as 
outside the vision of webcontinuations

The wiki smashed down the wording how Sylvain and me started 
understanding each other... if that is not introducing the same 
concepts to you, please feel free to ask clarification on those 
parts that are not making sense to you, I (and hopefully Sylvain 
who is far better at it then me) will try to do my best to 
explain differently and/or better

I spent some time to express myself carefully, but that is no 
guarantee towards a clear resulting text of course...

sigh, I wish I could do it in dutch, and on a whiteboard with you 
challenging and asking questions around me

bottom line is Bertrands mail though
it's about interfaces: if we can find some abstraction that 
suites us all, then what is the problem?

-marc=

> 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>

-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at              http://radio.weblogs.com/0116284/
mpo@outerthought.org                              mpo@apache.org


Mime
View raw message