cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Flow result storage : let's fix it before its too late !
Date Tue, 04 Mar 2003 10:16:59 GMT
Sylvain Wallez wrote:

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

Sorry, Sylvain, but I completely agree with Chris here.

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


The flow is about 'flow', it's about procedurally describing FSM 
transitions. it's totally incorrect to state that 'flow := business 
logic' because it is true that business logic influences the flow, but 
the other way around it's not true.

We don't use MVC, because MVC is too simple and mixes too many concerns 
in the 'controller/model' realms. But at least clears the fact that the 
'view' is totally separated.

if you start giving access from the view to the model, you make concerns 
overlap because part of the flow-logic gets connected to the 'view'.

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

The flow doesn't stop you from using ObjectModel-aware pipeline 
components, but as far as generating the 'view' of a controller-driven 
state, it's the controller that should drive the process. The 
controller, in our case, it's the flow layer.

Example: suppose that you want to display a request parameter in a XSP 
that was triggered by a flow call. You could do it in two ways:

1) using accessing the request directly from the XSP

2) accessing a parameter given by the flow, which accessed the request 

Which one is better?

The second.

Why? because the information on 'what' request parameter to use, was 
probably dictated by the flow itself. So, the contract created by the 
request parameter is only included in the flow layer and doesn't 
crosscut the view part.

The view has a totally different contract with the controller, which is 
the name of the parameter passed by the flow.

The better defined and well isolated the contracts, the cleaner and 
easier SoC-oriented-programming becomes, reducing maintenance costs in 
the long run by *orders* of magnitude.

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

Do you still feel the same after the context I've given you above?

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

My vision is that people should be suggested to see the flow as *THE* 
glue between views. In short, the natural programmatic side of the 
sitemap, which is a role that now actions have and took because of no 
real alternative.

As much as we don't specify

  <act ...>
   <generate src="{action:whatever}"/>

I really don't see why we should 'namespace' the flow variables more either.

But maybe there is something in your reasoning that I'm missing.

Stefano Mazzocchi                               <>
    Pluralitas non est ponenda sine necessitate [William of Ockham]

View raw message