Leszek Gawron wrote:
Daniel Fagerstrom wrote:
<snip/>
Are you certain about that it doesn't work for properties? I can't test right now, but looking at http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/blocks/scratchpad/java/org/apache/cocoon/environment/TemplateObjectModelHelper.java?rev=27976&view=markup
in DynamicMap.getDynamicInfo it looks to me that it handle properties. ...
result = PropertyUtils.getProperty(*this*.information, key.toString());
Misunderstanding. You cannot access "protocol" attribute. meaning
$cocoon/request/protocol gets the property and the syntax does not provide a way do do request.getAttribute( "protocol" );
Ok. The fact that the property shadows the attribute is a "feature" of making the request attributes accessible through $cocoon/request/myAttribute. One could of course let the attribute shadow the proprty instead. But the shadowing is a result of the original FOM design.
IMO we should make the Request interface bean friendly and add the methods:
Map getParameters(); Map getAttributes();
You won't reach those as collection in HttpServletRequest
http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/http/HttpServletRequest.html
I know, but we have an own environment abstraction, so we can have stuff that isn't part of the servlet definition. For the implementation we just need to wrap the parameters and attributes as maps in HttpRequest.
Sure, and we should solve it. Just wanted to point out that it not is an effect of the JXTG refactoring.Of course there are similar problems with session and context.
It is a serious blocker for users to just try to switch to 2.2-dev and use new JXTG.
IIRC it has nothing to do with the new JXTG, it didn't work with the original either. It is, IIRC, an effect of the refactoring of FOM in 2.2.
yes but it affects JXTG a lot.
/Daniel
