Here are the vote results:

10 +1 for "[ ] Go ahead and implement the environment extensions proposed above"
and no votes for the rest of the alternatives.


I'll implement the proposed extensions ASAP.

We have an ongoing discussion about how to handle local and global request attribute scope, see the vote thread http://marc.theaimsgroup.com/?t=111590936900001&r=1&w=2 and http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111598223123056&w=2, http://marc.theaimsgroup.com/?t=111598533700001&r=1&w=2. But I don't think we need to wait on that discussion. Making all uses of the environment interafaces depend on abstract Request, Session and Context classes will make it rather easy to implement whatever we decide for the request attributes.

/Daniel

Daniel Fagerstrom wrote:

To simplify and make the environment handling in flow, jxtg, modules and possibly other places more coherent, I propose that we extend the Cocoon environment apis with some utility methods that makes the environment more reflection friendly. See http://marc.theaimsgroup.com/?t=111581983200001&r=1&w=2 for motivation, discussion and technical issues.

More specifically I propose is that we extend o.a.c.environment.Request with:

 Map getAttributes();
 Map getParameters();
 Map getHeaders();

and o.a.c.environment.Session and o.a.c.environment.Context with:

 Map getAttributes();

The utility methods will be implemented in terms of current environment methods in abstract base classes, so for the various environments in Cocoon core and blocks the only difference will be that they will extend the abstract base classes instead of implementing the interfaces directly.

As Java faces use getAttributeMap() etc and servlet 2.4 has the method getParameterMap() in ServletRequest, we could consider using such name convention instead. But that leads to "request.parameterMap.blah" instead of "request.parameters.blah" which is different from our current use and in Sylvain's and my opinion looks ugly.

Please cast your votes:

[ ] Go ahead and implement the environment extensions proposed above.
[ ] Implement the environment extensions but use the *Map() syntax instead.
[ ] Don't extend the environment.


/Daniel




Reply via email to