Return-Path: 
 <cocoon-dev-return-33259-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 99391 invoked by uid 500); 25 Nov 2002 19:42:58 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 99370 invoked from network); 25 Nov 2002 19:42:58 -0000
Date: Mon, 25 Nov 2002 19:39:08 +0000
Subject: Re: Flow wishlist :)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v548)
From: Jeremy Quinn <jeremy@media.demon.co.uk>
To: cocoon-dev@xml.apache.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <3DE27300.8010209@apache.org>
Message-Id: <906115EF-00AD-11D7-B038-0003935AD2EE@media.demon.co.uk>
X-Mailer: Apple Mail (2.548)
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N


On Monday, Nov 25, 2002, at 18:59 Europe/London, Stefano Mazzocchi 
wrote:

> Hunsberger, Peter wrote:
>>> hmmmm, hmmmm, hmmmm, I have FS alarms ringing all over the place in 
>>> my head, but I have several great examples of where having that 
>>> would rock the planet.... but still, I'm afraid of people going back 
>>> adding programmatical logic to the sitemap....
>>>
>>> ... but it would be *so* cool to have a Workflow definition language 
>>> created as markup and then having a pipeline that generates the 
>>> flowscript by XSLT transformation!
>> I've been exploring the ability to define flow via XSLT and parsed 
>> markup
>> for some time now. I've a conceptual design in my head so far, but it 
>> is
>> very different from what exists in Cocoon so far, and different from
>> generating flowscript:  it seems to me that the essential requirement 
>> here
>> is just to be able to drive Cocoon via XSLT parsing of the current 
>> context
>> (request, session, etc. as the user sees fit).

<snip/>

>
> Ok, we'll keep this on the stack of 'possible wild proposals', ok? :)
>
> No, seriously, I'm very happy when people think about radically 
> different approaches to solve the same problems because that's how 
> innovation takes place.
>

Gosh!

I was expecting to see Stefano blow up there!! ;)

What you are describing sounds very like a common Cocoon 1 webapp 
model, whereby XSLT Stylesheets would use data in the DOM and internal 
logic to inject Processor Instructions to direct transformation flow.

I still find myself wanting pipelines that will react to changing data 
in the pipeline, ie, changes the processing path by changes in the 
data. But you are in a world of pain trying that in Cocoon now, it's 
not the way you are supposed to work .... you can't suddenly say, Ohh 
look, I reckon I need to run the SQLTransformer on that .... unless you 
always put it on your pipeline whether it is needed or not. Unless you 
have a MetaTransformer ... applies whatever Transformers are needed, 
that are registered to handle that namespace.

In fact thats analogous to your pipeline fragments you want to call 
from inside another pipeline, he! he! ;) a pipeline with no generator 
and no serializer is a meta-transformer! (head down ;)

regards Jeremy


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org