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.
Note that I personally prefer writing "request.parameters.blah" rather than "request.parameterMap.blah" which just looks ugly!
Sylvain
-- Sylvain Wallez Anyware Technologies http://apache.org/~sylvain http://anyware-tech.com Apache Software Foundation Member Research & Technology Director
