cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Discussion of Flow Issues
Date Mon, 17 Mar 2003 22:33:23 GMT
Stefano Mazzocchi wrote:

> Sylvain Wallez wrote:
>> What I suggested in the mail linked above is to use the object model, 
>> already used as a communication means between the environment and 
>> other components to communicate flow results. This suggestion comes 
>> both from the fact that the object model is the "natural" way for the 
>> environment to communicate public information to other components, 
>> and from the fact that we can consider flow data as some additional 
>> data available in the sitemap when called from a flow script.
>> 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.

So adding flow values to the object model shouldn't be a problem when 
they are either manipulated abstractly as described above or simply ignored.


>> I'm not sure this "FOM" thing has been defined compared to the 
>> Environment's object model. 
> This was my and Pier's concern: we need to define the FOM with the 
> same care we took to define the rest of the contracts with the Cocoon 
> system and it was not done until we raised the thing.
> Having you and Vadim discussing this with Chris, Pier and me is a very 
> good thing because it goes toward that community-driven design I was 
> looking for. 

Yep. I jumped into this discussion since I felt the need for this 
community-driven polishing and also to force me to finally go into this 
nice stuff ;-)

>> My POV is that the FOM is the set of objects that are visible as 
>> global variables in a flow script.
>> This must include :
>> - the Environment's object model (but not the Environment itself),
> yes. note also that with javascript we can do very nice syntax-sugar 
> things like
>  cocoon.request.blah
> would do the same as a much more verbose
>  cocoon.getRequest().getParameter("blah")
> which would bring us the scriptability and ease-of-use of web 
> scripting solutions (which are so popular because very easy to read 
> and write) with the solidity of a well-defined OO framework.

Yep. I like that too.

>> - Avalon-related objects that Java components (as opposed to 
>> JavaScript) obtain through the Avalon lifecycle interfaces. These are 
>> the Logger, the (Avalon) Context, and the ComponentManager. 
> The logger is available, we just need to define how.
> I already asked for a direct hook to the component manager.
> Why would you need access to the context? 

Because it can contain some useful data for the flow or Java classes 
called by the flow such as the work directory (makes me think that a 
"work:" protocol would be nice) or the environment context (webapp 
resources, deployment parameters, etc).

>> I don't know if there's a need for a Configuration.
> I would say no. The flow is not a component 

I was wondering if there may be some "generic" flow programs that could 
be parameterized through a configuration, but this finally smells FS. So 
no Configuration.

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

>> The FOM also provides some methods not related to any of the above 
>> objects such as sendPage().
> methods that I want to see removed from a global namespace and placed 
> into the cocoon object for clarity and cognitive scope. 

Me too :-)


> In my mind, this means that not many understand that the 'window' 
> object is transparently mapped to the global unnamespaced object.... 
> but it creates a mess because you could have 'status' defined in your 
> scripts as well.
> This is why I want a clean unnamespaced object.
> I would not mind log methods such as
>  info("blah");
>  error("blah");
>  debug("lkj");
> but that should be it. 

Even these. Let's attach them to a "logger" object : log.debug("blah"),"foo"), etc.

>> This is mainly a naming and classification problem : how do we 
>> organize these objects available to the JS script ? Should all the 
>> FOM be defined as global variables, or available as properties of 
>> some "classifier" objects, e.g. "cocoon.request", 
>> "cocoon.sendPage()", "avalon.logger", "avalon.manager" ? I personnaly 
>> would go for the second choice.
> Totally!
> Note, however, that I would like to "hide" the complexities of Avalon 
> as much as possible.
> So, I would go for
>  global -> contains global log methods, no properties 

-1 (see above)

>  cocoon -> cocoon methods + component management methods 

CM methods = lookup() and release() ?

>  cocoon.request -> access to the request
>  cocoon.response -> access to the response
>  cocoon.context -> access to the context 

Beware : _Avalon_ context, or _environment_ context ?

BTW, I've been thinking for a long time to rename 
o.a.c.environment.Context to EnvironmentContext to avoid those naming 
conflicts. Isn't the 2.1 a good opportunity to do that ?

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

>  2) do we need access to the response? setting headers is the only 
> thing that comes to mind, but that is potentially abusable, expecially 
> on things like cache headers and such. maybe we should leave this out 
> as well for now. 

+0. Let's not include it for now and see if it's needed later.

>  3) avalon component management should be done thru the 'cocoon' 
> object because it's cocoon, in fact, that provides those components to 
> you. the fact that they are managed internally by avalon doesn't make 
> any difference for joe-flow-user, nor should.

+1. But beware of "context" which is an ambiguous word. But if we 
introduce a "work:" protocol and give acess to the environment context, 
the Avalon context may be useless.

> What do you think? 

Community-driven polishing at work ;-)


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message