cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [RT] POJOfied Environment
Date Thu, 12 May 2005 13:36:50 GMT
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: 
>> http://java.sun.com/j2ee/javaserverfaces/1.1_01/docs/api/javax/faces/context/ExternalContext.html

>>
>>
>> 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.

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

/Daniel


Mime
View raw message