cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <lgaw...@mobilebox.pl>
Subject Re: [RT] POJOfied Environment
Date Wed, 11 May 2005 14:08:33 GMT
Leszek Gawron 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.
> 
> totally +1. The inconsistency between what is available from flow, JEXL 
> and JXPath is irritating.
not _what_ but _how_ really

-- 
Leszek Gawron                                      lgawron@mobilebox.pl
IT Manager                                         MobileBox sp. z o.o.
+48 (61) 855 06 67                              http://www.mobilebox.pl
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65

Mime
View raw message