cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: Discussion of Flow Issues
Date Tue, 18 Mar 2003 03:21:38 GMT
Sylvain Wallez wrote:

> Stefano Mazzocchi wrote:
>> Sylvain Wallez wrote:
>>> So we need two more values in the object model Map : one for the 
>>> value dictionary, and one for the continuation.
>>> How does it sound ?
>> I love it, but, as Carsten correctly pointed out, this will make it 
>> harder to separate the flow.
>> (I'm basing my reasoning on the anti-pattern assumption that if a 
>> module separation requires code preprocessing there is something wrong) 
> I don't think this will make it difficult to separate it : the object 
> model is a Map which can hold any kind of objects, and 
> instrospection-based accessors such as JXPath don't care about the 
> actual class of objects.

1) Helper functions like getContinuation() in ObjectModelHelper are not 
2) FlowVelocityGenerator, it has some clever hack on 130 lines or so 
specifically for the flow bean (see "Hack? I use JXPath to determine the 
properties of the bean object");
3) jpath logicsheet right now instead of being generic is hardwired to 
the flow too;

It's already not easy to separate! I can think of how to resolve issue 1 
(dedicated FlowObjectModelHelper: ugly, but works) and 3 (flow 
logicsheet for flow related stuff; jxpath logicsheet for generic stuff), 
not sure about 2 though. Extra Velocity generator is not nice.


>>> - the Redirector, currently available to actions (I consider 
>>> redirecting as a particular case of a view).
>> Hmmm, I'm not sure: why would you want a redirector when you have the 
>> sendPage() method? 
> To send a redirect directly to the client, without going through the 
> sitemap. Considering the sendPage() method, a redirect() method would 
> be better than a Redirector object. 



>> So, I would go for
>>  global -> contains global log methods, no properties 
> -1 (see above) 

"No" to global, agree.

>>  1) do we really need the session object? the flow is in fact 
>> deprecating the use of sessions for storing stateful data. I would 
>> love to *force* people to think into this way by not making the 
>> session available to them. We can always add it later if users really 
>> push us for it. 
> +1. Moreover, the inadequate use of sessions to store data my 
> completely break what the flow is giving us through continuations. 

-0: Put session there, don't advertise it. Presence of the session 
object might facilitate migration from one approach to another, also 
will allow integration between different parts.



View raw message