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?
