cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <vadim.gritse...@verizon.net>
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 
separatable;
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.

<snip/>


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


+1


<snip/>

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


Vadim

<snip/>



Mime
View raw message