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
