Return-Path: 
 <dev-return-44471-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 1922 invoked by uid 500); 4 Jul 2003 20:32:27 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
list-post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 1908 invoked from network); 4 Jul 2003 20:32:27 -0000
Received: from apate.telenet-ops.be (195.130.132.57)
  by daedalus.apache.org with SMTP; 4 Jul 2003 20:32:27 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by apate.telenet-ops.be (Postfix) with SMTP id E447C38162
	for <dev@cocoon.apache.org>; Fri,  4 Jul 2003 22:32:32 +0200 (MEST)
Received: from outerthought.org (D5E0AA8A.kabel.telenet.be [213.224.170.138])
	by apate.telenet-ops.be (Postfix) with ESMTP id BA023380ED
	for <dev@cocoon.apache.org>; Fri,  4 Jul 2003 22:32:32 +0200 (MEST)
Message-ID: <3F05E460.1020609@outerthought.org>
Date: Fri, 04 Jul 2003 22:32:32 +0200
From: Steven Noels <stevenn@outerthought.org>
Organization: Outerthought
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] Generalizing the flow
References: <3F058848.9080502@anyware-tech.com> <3F05C571.2070202@verizon.net>
In-Reply-To: <3F05C571.2070202@verizon.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

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