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.
<snip/>
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 :-)
<snip/>
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"), log.info("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 ?
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.
+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
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
