Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3E63D5E6.6010007@anyware-tech.com>
Date: Mon, 03 Mar 2003 23:23:34 +0100
From: Sylvain Wallez <sylvain.wallez@anyware-tech.com>
Organization: Anyware Technologies
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.2) Gecko/20021126
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Flow result storage : let's fix it before its too late !
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi all,

A rather provocative subject, so let me first say that I like the flow, 
even if unfortunately I didn't have the occasion to use it up to know. 
Ovidiu did a wonderful job and Adrew is now adding features that make it 
more usable.

But I think we reached a point where we have to be careful at how the 
flow is slowly spreading inside other components and do some design 
before it's too late. This is mainly about the way the flow gives its 
output to other components : it adds two attributes to the *Environment* 
object, which is an object used internally by the pipeline machinery, 
and *should not be used* by other components (nor shoud it 
theroretically be accessible).

The way this Enviromnent object is fetched says it by itself :
  public void setup(SourceResolver resolver, Map objectModel, String 
src, Parameters params) {
    Object bean = ((Environment)resolver).getAttribute("bean-dict");
    WebContinuation kont = 
(WebContinuation)((Environment)resolver).getAttribute("kont");
    ...

This is a hack that relies on the fact that the SourceResolver also 
implements Environment, which is absolutely not guaranteed by its 
contract ! Furthermore, this "resolver" parameter in C2.1 should be 
considered deprecated and is replaced by the Excalibur SourceResolver 
which is a regular component looked up on the ComponentManager and 
doesn't implement Environment !

So why don't we use the ObjectModel to pass the flow information ? It 
already contains the request and the response, and this seems the 
natural place for flow values. And more : if we consider components such 
as FlowVelocityGenerator, why would we want to publish only flow data 
and not elements of the object model ? If everything was in the object 
model, we could have some generic publication code that would publish 
all that is in the object model, regardless of what it actually is, and 
thus no need for a second VelocityGenerator.

Thoughts ? What's the reason for using the Environment ?

Also, I prefer longer but more explicit names than "$this" to access the 
flow bean : "$flowDict" is not much longer but way more explicit in the 
huge name base that is Cocoon. Oversimplifying names leads to too much 
magic that kills the understandability of the whole thing.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }