cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject [Vote results] POJOfied Environment
Date Mon, 16 May 2005 08:25:18 GMT
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
>


Mime
View raw message