cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] POJOfied Environment
Date Thu, 12 May 2005 14:13:55 GMT
Daniel Fagerstrom wrote:

> Sylvain Wallez wrote:
>> Daniel Fagerstrom wrote:
>>> In the current #{$cocoon/request/request/protocol} thread we (again) 
>>> discuss problems with the environment access in JXTG. The problems 
>>> comes from that we have copied part of the servlet api in our 
>>> environment abstraction and that it contains methods of the type 
>>> "Object getAttribute(String)", which isn't recoginized by typical 
>>> bean reflection or expression languages.
>>> To solve this we have implemented (far to many) wrappers in modules, 
>>> flow, jxtg and probably other places. In flow/jxtg, the situation is 
>>> more or less a mess.
>>> Anyway, to save us from wasting our time in reinventing the "servlet 
>>> api reflection" wheel again and again in the future, we should IMO 
>>> instead "POJOfy" our environment abstraction. So that any decent 
>>> bean reflection implementation can access the attributes and 
>>> parameters whithout any extra hacks.
>>> As Vadim pointed out in an earlier discussion this is done in Java 
>>> faces: 

>>> So what I propose is that we extend o.a.c.environment.Request with:
>>>  Map getAttributes();
>>>  Map getParameters();
>>>  Map getHeaders();
>>> o.a.c.environment.Session and o.a.c.environment.Context with:
>>>  Map getAttributes();
>>> possibly there are more. Java Faces use getRequestMap etc instead, 
>>> but the plural "s" is closer to our current conventions.
>>>                         --- o0o ---
>>> As this is an interface change I'm of course only talking about 2.2. 
>>> From an implementation POV we could implement the new methods in 
>>> terms of the old ones in an AbstractRequest etc, so it would be 
>>> quite easy to introduce it in the various environments.
>>> Of course we could put the above methods in still another wrapper, 
>>> but I think we have tried that path without success allready, so I 
>>> would prefer to put it directly in the environment.
>>> For those not familiar with the Cocoon internals it should maybe be 
>>> mentioned that although the Cocoon environment is close to the 
>>> HTTPServlet environment it is not the same, so we are free to add 
>>> whatevere we want to.
>>> WDYT?
>> +1.
>> The case of parameters however should be considered carefully, as 
>> ServletRequest provides getParameterMap() since servlet 2.4 (or 
>> 2.3?). Having it named getParameter() in our environment may be 
>> confusing for people used to the servlet API.
> That complicates the question a bit.
>> Note that I personally prefer writing "request.parameters.blah" 
>> rather than "request.parameterMap.blah" which just looks ugly!
> Agree, the plural "s" also corresponds to our current use and looks 
> much better. So I think we should go for getParameters() etc rather 
> than getParameterMap etc. It doesn't seem to be a perfect solution for 
> this case.
> If no one protests I think we should go ahead and implement it. Or do 
> we need a poll or vote? We need to extend the interfaces and write 
> Abstract[Request|Session|Context] that implements the new methods, 
> this can be done in terms of the various maps from 
> o.a.c.faces.context. Then the http, commandline and wrapper 
> environments should extend the abstract environments rather than 
> implement the interfaces.

A vote would be good as the environment is an important set of interfaces.

> Are there any environment implementations outside o.a.c.environment?

Have a look at cron, portal and src/tests.


Sylvain Wallez                        Anyware Technologies  
Apache Software Foundation Member     Research & Technology Director

View raw message