cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
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: 
>>> 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.


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

-- 
Sylvain Wallez                        Anyware Technologies
http://apache.org/~sylvain            http://anyware-tech.com
Apache Software Foundation Member     Research & Technology Director


Mime
View raw message