cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Discussion of Flow Issues
Date Mon, 17 Mar 2003 20:02:59 GMT
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)

>>> 2) Concerns with exposing the componentManager:
>>>
>>>    http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104687345726726&w=2
>>>    http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104687863701233&w=2
>>>
>>> I personally do not know what the proper solution here is. Can 
>>> someone explain the proper use of component managers and make a 
>>> suggestion on how to solve this?
>>
>>
>>
>> I think that a way to solve this would be to have a direct FOM hook to 
>> the cocoon component manager... but this should not allow people to 
>> have access to sitemap components, only to those components defined in 
>> roles.
>>
>> But I'm thinking out loud here. 
> 
> 
> 
> 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.

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

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

>I don't know if there's a need for a Configuration.

I would say no. The flow is not a component

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

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

>>> 3) Duplication of functionality between VelocityGenerator and 
>>> FlowVelocityGenerator:
>>>
>>>    http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104673257019781&w=2
>>>
>>> This is clearly bad, I agree. I think these could be merged back 
>>> together - the old behavior would apply if the flow context object 
>>> isn't available. But this probably depends somewhat on the answer to 
>>> (1).
>>
>>
>>
>> Ok, so you are stating that once we solve 1) we solve 3) as well? 
> 
> 
> 
> Could be ;-) If flow data goes through the object model, publishing the 
> object model to the Velocity engine could solve the problem.

Great.

[snip]

> I share your "attach-a-method-to-an-object" concern, which certainly 
> comes from our heavy Java background.

I'm sure it does, but after playing pretty hard with javascript for 
DHTML, I can tell you that the hardest thing for me to graps is the 
concept of why everybody uses

  alert("blah")

why they use

  window.status = "blah"

but never

  window.alert("blah");

and

  status = "blah";

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.

> 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
  cocoon -> cocoon methods + component management methods
  cocoon.request -> access to the request
  cocoon.response -> access to the response
  cocoon.context -> access to the context

NOTE:

  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.

  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.

  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.

What do you think?




Mime
View raw message