cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: Flow result storage : let's fix it before its too late !
Date Tue, 04 Mar 2003 09:34:29 GMT
Christopher Oliver wrote:

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


I'm very sorry if I offended you, since it wasn't intended so and I know 
the good things you've done up to now. I'm ringing a bell (and 
considering Gianugo and Stefano's answer it has been heard) about the 
current trend of the flow to provide too much features in its core and 
"insinuate" in other components because of its specificities (mainly 
related to using the Environment). We started to refactor the whole code 
base in blocks, and the flow starts going the opposite way.

Let's structure the flow in blocks : for example, can't the JS database 
stuff go into the database block ? The flow may provide some RAD-ish 
features, but they shouldn't be hard linked into the core.

>> 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).
>
<snip/>

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


That's good.

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


I don't agree here : the flow is about business logic, and the 
presentation layer is about... presentation, which may often depend on 
information available in the request that aren't of any interest to the 
business logic. To name a few, we have the target language, the 
user-agent, the host name (which can decide of the skin in case of 
virtual host), etc.

This is also a wonder I have about the current way the flow is perceived 
: by filling an important hole in Cocoon, it seems to me the flow is now 
surpassing its initial role. The flow isn't responsible for _all_ data 
that drive the system output, but only (and this should not be taken as 
a pejorative restriction) of the business data.

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


The problem is not about "$this" but more about populating the flow data 
as toplevel variables. Explicitely naming the flow through a "$flowData" 
or something like that makes it more understandable about where this 
data comes from and where the user can know more about it.

Sylvain

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



Mime
View raw message