Daniel Fagerstrom wrote:
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.
You're right. We could take the approach Carsten implemented in
DynamicMap. Request parameters parameters could be lazily fetched from
underlying implementation and put into a map. Still we could not provide
an iterator...
--
Leszek Gawron [EMAIL PROTECTED]
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
