cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Royal <>
Subject Re: data goes in, data goes out (RT in disguise)
Date Thu, 29 Nov 2001 20:52:43 GMT
On Thursday 29 November 2001 02:18 pm, you wrote:
> In essence, we are merging concepts of Cocoon with the Handler concept of
> Axis.  There is now no distinction between an Action and a Transformer that
> acts on the request markup.  By arranging the order of these
> Transformer/Handlers we can elegantly create powerful web applications. 
> This might be more inline with the reactor pattern--but nothing like Cocoon
> 1.

Let's take the classic posting data to a form example, how would this work in 
a bidirectional XML pipeline? User posts data to the webserver, this is then 
transformed into an XML request and an incoming pipeline to the 
service(generator) is constructed. Would the Transformers on that pipeline be 
destructive? That is removing data from the XML request and applying it to 
the external store? (The opposite of a transformer that watches for tags and 
reads from the external store).

Should the incoming pipeline whittle the XML request down to nothing by the 
time it reaches the service, or does the XML go through the service, with the 
service acting as the U-turn point?

The other thing is how would caching play into such a beast? I think that's 
an important concept to thing about up front. With SOAP its not really an 
issue since more often than not you don't want to cache function calls, but 
for web content caching is king. I guess if the input pipeline and output 
pipeline are separate, then the output pipeline can still be partially 
cacheable similar to how cocoon acts today?

For webapps, this could be *very* powerful if attached to something like 
XML-Schema, since you could then have an input transformer that does datatype 

> While I can appreciate the difference between Session and Request
> variables, there are just too many access points to worry about. 
> Environment simplification is another matter altogether.

I enjoy having two different places to stick things now, as by making Request 
attributes, I know they will all start as null on the next request. Of course 
you could make the Environment have multiple setAttributes, one for 
persistent attributes and one for the current active transaction.

> (because I was writing in the stream of consciousness), hopefully somebody
> will get something out of the ideas I presented.

Slowly processing :) My comments might not make a ton of sense either, but 
its important to get words tossed around.

peter royal ->

To unsubscribe, e-mail:
For additional commands, email:

View raw message