Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3E63DB0E.4020408@verizon.net>
Date: Mon, 03 Mar 2003 14:45:34 -0800
From: Christopher Oliver <res1cf5x@verizon.net>
Reply-To: coliver@apache.org
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US;
 rv:1.0.1) Gecko/20020823 Netscape/7.0
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: Flow result storage : let's fix it before its too late !
References: <3E63D5E6.6010007@anyware-tech.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

First of all Sylvain, my name is Chris Oliver, not Andrew C. Oliver 
(that's acoliver@apache.org).

Sylvain Wallez wrote:
> 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. 

I'm glad I've stimulated your interest. That was my intention - even if 
you choose to cast it in terms of a perceived lack of design. The 
changes I've made are not written in stone. On the contrary, I expect 
them to change based on observations by others, including yours.

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


I agree with you here. It should be no big deal to move the storage of 
these values to the objectModel.

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

Well, actually I don't agree with you now. The flow script establishes a 
contract with the presentation layer determined by the object it passes 
to sendPage*() or the object it uses for the XMLForm model. This, and 
only this, should be supplied to the presentation layer. The 
presentation layer should not have access to the request, session, etc, 
unless references to these are explicitly passed by the flow script.

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

Actually, under normal circumstances you never need to use $this. Its 
only reason for existence is to provide a means of disambiguating the 
built-in "continuation" property, in case the bean also has a property 
called "continuation":

$continuation - the continuation object
$this.continuation - a property named "continuation"