Thanks for your response.
I am going to try this and see if this works. The RequestMethodSelector
is also available in Cocoon 2.2. I just did not expect that one must use
it to identify the request method in the sitemap, given that the request
object is available as cocoon.request in flow as well.
On 09/21/2010 04:40 PM, florent andré wrote:
Hi Andre,
Thanks for your day to day research feedback.
In Lenya (widely use of cocoon), we have this :
<map:select type="request-method">
<!-- many client editors like to PUT changes -->
<map:when test="PUT">
<map:mount uri-prefix=""
src="{fallback:lenya/modules/webdav/sitemap.xmap}" check-reload="true"
reload-method="synchron"/>
</map:when>
</map:select>
So the request-method selector seems to detect PUT.
The selector is implemented here :
cocoon_2_1_x/src/java/org/apache/cocoon/selection/RequestMethodSelector.java
With this code :
String method = ObjectModelHelper.getRequest(objectModel).getMethod();
Note that is cocoon 2.1, but normaly no big changes with 2.2.
Maybe selector and input don't have the same implementation ?
Just some piece of informations I have. I'm not enough inform about
how cocoon deal with request for helping more.
HTH
++
On 09/21/2010 03:10 PM, Andre Juffer wrote:
Dear All,
in a previous thread, I was trying to understand why I could not see the
request parameters of a HTTP PUT request using the
cocoon.request.getParameter("...") family of methods in flowscript.
Conclusion: For a PUT request, according to specification, the servlet
engine is -not- required to parse the request for making the parameters
available through request.getParameter("..") and consequently also
cocoon.request.getParameter("...") will not return a value (just
'null'). [1]
One remedy is assume POST requests (client side) instead for the time
being, despite differences in the meaning of POST and PUT with regard to
RESTful applications.
There is still one other issue to be solved. In the case of a PUT
request (or any other HTTP request for that matter), my understanding is
that I should be able to identify the request HTTP method in flowscript
by cocoon.request.getMethod() or in a pipeline using <map:parameter
name="method" value="{request:method}" />. I find in either case that
this parameter's value is always GET, whatever the original request
method received by the servlet engine was. It seems that the original
request method value is simply lost somewhere, -before- the request is
being handled in the sitemap.
I now seek answers to the following:
1. Can one of you confirm (or not) that this is indeed the case. That
is, cocoon interferes with the original request and makes it a (or
creates a new) GET request. It is certain that the servlet engine
receives the PUT request in good order. It is also certain that the
servlet engine is not changing the original request. It simply passes it
on the cocoon-based webapp.
2. If item 1 above is in fact true (and I really hope this is not the
case), what would be solution to overcome this issue. I could image
making a filter that adds an extra parameter or attribute
'request-method' or something to the request that retains the original
HTTP method and query for its value in the sitemap or in flowscript. I
have to hope that cocoon retains this extra parameter or attribute when
it receives the request.
I would very much appreciate any response in this matter. I could not
find answers on the cocoon email lists or in the documentation,
unfortunately.
[1]
http://mail-archives.apache.org/mod_mbox/cocoon-users/201009.mbox/browser
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
--
Andre H. Juffer | Phone: +358-8-553 1161
Biocenter Oulu and | Fax: +358-8-553-1141
Department of Biochemistry | Email: andre.juf...@oulu.fi
University of Oulu, Finland | WWW: www.biochem.oulu.fi/Biocomputing/
StruBioCat | WWW: www.strubiocat.oulu.fi
NordProt | WWW: www.nordprot.org
Triacle Biocomputing | WWW: www.triacle-bc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
