Re: Cocoon 2.2 PUT HTTP request
On 09/22/2010 01:27 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andre, On 9/21/2010 4:26 PM, Andre Juffer wrote: I got it working now. It is really in the details. I always relied upon a PUT request like http://localhost:/equipment expecting to see the request method set to PUT. In fact, it was always GET. If, however, one employs http://localhost:/equipment/ ---^ (Notice the forward slash at the end!) Wow! So, your server was issuing a redirect to the client? That usually only happens when you have something else going on.Is /equipment the context path of your webapp? If so, I think you have to have /something/ after the /equipment, otherwise it's a request for no resource at all. The 'equipment' is in fact one of the blocks of my cocoon 2.2 based web application. I have currently three blocks, ui, equipment, and eap, the latter produces the war file (eap.war) that is to be placed in the webapps directory of some servlet engine. With cocoon, one can also immediately test your application by going into one of the blocks (usually the eap) block and enter mvn jetty:run instead of copying the eap.war to the webapps directory of the servlet engine. One needs to point your browser to http://localhost:/ui/start (so without the 'eap' in the path) and posting equipment would require a POST request using http://localhost:/equipment/ while updating with PUT would require http://localhost:/equipment/12345 Note that the latter can also be used in a GET request. In addition, a GET request like http://localhost:/equipment/ results in a list of equipment (with or without the forward slash). For the equipment block, equipment is than the context path. The equipment block's sitemap contains map:match pattern=* map:call function=equipmentHandler / /map:match meaning that -all- requests results in a call to equipmentHandler. The path within the equipment block does not contain anymore 'equipment'. The issue with the extra forward slash at the end is probably a cocoon thing, and because I have map:match pattern=* in the sitemap, I guess. Previous applications I have made with cocoon did not use the map:match pattern=* so this never occurred. I had things like map:match pattern=manage/* and I was checking for a 'task' request parameter like in http://localhost:/equipment/manage?task=update?id=12345 to decide what to do. I never was thinking in terms of REST. The whole problem of not having the request parameters never occurred, simply because the request parameters where always included in the path as above. Now, using dojo.xhrPost() or dojo.xhrPut() on the client (Dojo Toolkit) , the actual request send to the server is assembled differently, and in the case of a POST or PUT request, the request parameters are not anymore encoded into the path. Therefore I ran into problems with PUT and POST. In all my previous emails, I used the PUT request as an example, but I could have used POST as well. I should note however, in context of REST, a PUT request for creating (so not updating) a resource like http://localhost:/equipment/ does indeed not make sense, as no identification of the resource is provided. Creating resources is done with POST if the server can decide on the path to (or ID of) the resource. If the client can decide on the resource path (or ID), a PUT is appropriate. Try confirming (say, with LiveHttpHeaders) that the PUT is being redirected by the server. This is what I see with LiveHttpHeaders: http://localhost:/equipment/ POST /equipment/ HTTP/1.1 Host: localhost: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.10) Gecko/20100915 Ubuntu/10.04 (lucid) Firefox/3.6.10 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Connection: keep-alive Content-Type: application/x-www-form-urlencoded; charset=UTF-8 X-Requested-With: XMLHttpRequest Referer: http://localhost:/ui/start Content-Length: 94 Cookie: JSESSIONID=hr0mt4clb1k4; webfx-tree-cookie-persistence=wfxt-4+wfxt-6; PPA_ID=9qtajhe4ckjkj3mr200ck8jbo3 Pragma: no-cache Cache-Control: no-cache name=hallotask=thallocategory=testingmanufacturer=testingdescription=halloownerId=3375104 HTTP/1.1 200 OK X-Cocoon-Version: 2.2.0 Content-Type: application/json; charset=UTF-8 Content-Length: 320 Server: Jetty(6.1.7) So, no redirect, as far as I can see. I did not think that was happening. Requests parameters are not available, at least not with Jetty 1.6.7 (and I would assume the same is true for tomcat 6 and 7, did not check). I've got an enhancement request in for TC 7, and I'm working on a patch. I have it working -- I'm just working on the unit tests and documentation, now. So, this leaves us with the issue with PUT not
Re: Cocoon 2.2 PUT HTTP request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andre, On 9/22/2010 3:36 AM, Andre Juffer wrote: Try confirming (say, with LiveHttpHeaders) that the PUT is being redirected by the server. This is what I see with LiveHttpHeaders: http://localhost:/equipment/ POST /equipment/ HTTP/1.1 No, I meant try to PUT to http://localhost:/equipment (no trailing slash) and see if the server redirects you. Also, it would be nice to to know what kind of redirect is being issued. If a 303 response is being generated, then the client is supposed to use a GET method for the followup request. Other response codes have other meanings. [W]ith cocoon one can create very easily various resource representation using XSLT, without the need the hardcode this into Java. Cocoon 3 (there is an alpha version) is better prepared for REST. Excellent. Good luck. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyaJEAACgkQ9CaO5/Lv0PBapgCeJuwk/PWW1x+mBKa8gA7x8k6J paUAnita0RxYiQkAVPogO19b/E+tmCzX =TbU7 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Cocoon 2.2 PUT HTTP request
On 09/22/2010 06:44 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andre, On 9/22/2010 3:36 AM, Andre Juffer wrote: Try confirming (say, with LiveHttpHeaders) that the PUT is being redirected by the server. This is what I see with LiveHttpHeaders: http://localhost:/equipment/ POST /equipment/ HTTP/1.1 No, I meant try to PUT to http://localhost:/equipment (no trailing slash) and see if the server redirects you. Also, it would be nice to to know what kind of redirect is being issued. If a 303 response is being generated, then the client is supposed to use a GET method for the followup request. Other response codes have other meanings. OK, sorry about that. Here is the output and I think you are right. It actually generates 302 instead of of a 303 response, but the effect is probably the same (according to Wikipedia). The second request is not mine and is actually a GET request. Note that cocoon 2.2 is about two years old and has not been updated since then. I hope cocoon 3 goes main stream soon now. http://localhost:/equipment PUT /equipment HTTP/1.1 Host: localhost: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.10) Gecko/20100915 Ubuntu/10.04 (lucid) Firefox/3.6.10 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Connection: keep-alive Content-Type: application/x-www-form-urlencoded; charset=UTF-8 X-Requested-With: XMLHttpRequest Referer: http://localhost:/ui/start Content-Length: 94 Cookie: JSESSIONID=hr0mt4clb1k4; webfx-tree-cookie-persistence=wfxt-4+wfxt-6; PPA_ID=9qtajhe4ckjkj3mr200ck8jbo3 name=testertask=testercategory=testermanufacturer=testerdescription=testerownerId=3375104 HTTP/1.1 302 Found X-Cocoon-Version: 2.2.0 Location: http://localhost:/equipment/ Content-Length: 0 Server: Jetty(6.1.7) -- http://localhost:/equipment/ GET /equipment/ HTTP/1.1 Host: localhost: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.10) Gecko/20100915 Ubuntu/10.04 (lucid) Firefox/3.6.10 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Connection: keep-alive Referer: http://localhost:/ui/start Cookie: JSESSIONID=hr0mt4clb1k4; webfx-tree-cookie-persistence=wfxt-4+wfxt-6; PPA_ID=9qtajhe4ckjkj3mr200ck8jbo3 HTTP/1.1 200 OK X-Cocoon-Version: 2.2.0 Content-Type: application/json; charset=UTF-8 Content-Length: 1838 Server: Jetty(6.1.7) -- Under 'generator' I find (note the redirect) #request# PUT http://localhost:/equipment PUT /equipment name=testertask=testercategory=testermanufacturer=testerdescription=testerownerId=3375104 #request# GET http://localhost:/equipment/ #redirect# GET /equipment/ [W]ith cocoon one can create very easily various resource representation using XSLT, without the need the hardcode this into Java. Cocoon 3 (there is an alpha version) is better prepared for REST. Excellent. Good luck. Thanks. And thanks again for your feedback. That was extremely helpful. I sincerely hope that you are able to get the request for a new feature related to PUT requests in the next version of Tomcat! Many users will be very about that (including me). André - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyaJEAACgkQ9CaO5/Lv0PBapgCeJuwk/PWW1x+mBKa8gA7x8k6J paUAnita0RxYiQkAVPogO19b/E+tmCzX =TbU7 -END PGP SIGNATURE- - 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
Cocoon 2.2 PUT HTTP request
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
--
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
Re: Cocoon 2.2 PUT HTTP request
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
Re: Cocoon 2.2 PUT HTTP request
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
Re: Cocoon 2.2 PUT HTTP request
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andre,
(Is everyone on the list named Andre? :)
On 9/21/2010 9:10 AM, Andre Juffer wrote:
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'll check to see what I can get from {request:method} in my sitemap.
Other {request:*} methods seem to be working okay, though. I am also
using Cocoon 2.1, but at (the other) Andre points out, the differences
shouldn't be great in these areas.
I'm still interested in how Cocoon passes parameters to functions. In
the code you posted before, it didn't seem like you were actually trying
to access that parameter. If you use {request:method} in your pipeline,
I suspect it will give you the right method as long as you read the
/parameter/ instead of trying to use cocoon.request.getMethod() as it
appeared you were doing.
I find the Cocoon documentation very difficult to navigate. Can you
point me to the documentation for calling javascript functions? All I
could find was this:
http://cocoon.apache.org/2.2/core-modules/core/2.2/844_1_1.html
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkyY36MACgkQ9CaO5/Lv0PALAgCgtih3jh2Z4nqm+RuRafLbGOEe
qCAAoLofwTo+Tah8/kyZlF2sA2B504Wh
=B+Zg
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Cocoon 2.2 PUT HTTP request
On 09/21/2010 07:38 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andre,
(Is everyone on the list named Andre? :)
No, there is Robbie as well!
On 9/21/2010 9:10 AM, Andre Juffer wrote:
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 usingmap: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'll check to see what I can get from {request:method} in my sitemap.
Other {request:*} methods seem to be working okay, though. I am also
using Cocoon 2.1, but at (the other) Andre points out, the differences
shouldn't be great in these areas.
I'm still interested in how Cocoon passes parameters to functions. In
the code you posted before, it didn't seem like you were actually trying
to access that parameter. If you use {request:method} in your pipeline,
I suspect it will give you the right method as long as you read the
/parameter/ instead of trying to use cocoon.request.getMethod() as it
appeared you were doing.
That's right. Both approaches are fine. I tend to use the
cocoon.request.get* because it is available anyways within flowscript
functions.
I find the Cocoon documentation very difficult to navigate. Can you
point me to the documentation for calling javascript functions? All I
could find was this:
http://cocoon.apache.org/2.2/core-modules/core/2.2/844_1_1.html
Yeah, it is not that well organized. Have a look at:
http://cocoon.apache.org/2.2/blocks/flowscript/1.0/1241_1_1.html
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkyY36MACgkQ9CaO5/Lv0PALAgCgtih3jh2Z4nqm+RuRafLbGOEe
qCAAoLofwTo+Tah8/kyZlF2sA2B504Wh
=B+Zg
-END PGP SIGNATURE-
-
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
Re: Cocoon 2.2 PUT HTTP request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andre, On 9/21/2010 2:04 PM, Andre Juffer wrote: On 09/21/2010 07:38 PM, Christopher Schultz wrote: I find the Cocoon documentation very difficult to navigate. Can you point me to the documentation for calling javascript functions? All I could find was this: http://cocoon.apache.org/2.2/core-modules/core/2.2/844_1_1.html Yeah, it is not that well organized. Have a look at: http://cocoon.apache.org/2.2/blocks/flowscript/1.0/1241_1_1.html In the examples, I see them use code like this: cocoon.request.get(foo) to get a request parameter. get() is not a standard method on HttpServletRequest, so this must be some kind of wrapper around HttpServletRequest. There seems to be nothing about working with map:parameter elements from the sitemap in the flowscript. :( - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyY/CgACgkQ9CaO5/Lv0PDbZgCfSd98cokDRntfHnLRMkDLduTz 0LAAoKlpGlBDntPj09UTTlyVID7OZkS+ =JCr8 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Cocoon 2.2 PUT HTTP request
On 09/21/2010 09:40 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andre, On 9/21/2010 2:04 PM, Andre Juffer wrote: On 09/21/2010 07:38 PM, Christopher Schultz wrote: I find the Cocoon documentation very difficult to navigate. Can you point me to the documentation for calling javascript functions? All I could find was this: http://cocoon.apache.org/2.2/core-modules/core/2.2/844_1_1.html Yeah, it is not that well organized. Have a look at: http://cocoon.apache.org/2.2/blocks/flowscript/1.0/1241_1_1.html In the examples, I see them use code like this: cocoon.request.get(foo) to get a request parameter. get() is not a standard method on HttpServletRequest, so this must be some kind of wrapper around HttpServletRequest. This provides an overview of the cocoon.request methods: http://cocoon.apache.org/2.2/blocks/flowscript/1.0/1383_1_1.html You will find there both cocoon.request.get(..) and cocoon.request.getParameter(..). I've used for other applications I've made in the past always the getParameter() function. Never worried about PUT requests. Check out the links on the left as well. There seems to be nothing about working withmap:parameter elements from the sitemap in the flowscript. :( Yeah, you're right. I thought it was explained there. There is indeed almost no information about map:parameter on the cocoon 2.2 site, except for http://cocoon.apache.org/2.2/core-modules/core/2.2/852_1_1.html However, on the cocoon 2.1 site, there is the following: http://cocoon.apache.org/2.1/userdocs/flow/sitemap.html - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyY/CgACgkQ9CaO5/Lv0PDbZgCfSd98cokDRntfHnLRMkDLduTz 0LAAoKlpGlBDntPj09UTTlyVID7OZkS+ =JCr8 -END PGP SIGNATURE- - 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
Re: Cocoon 2.2 PUT HTTP request
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andre,
On 9/21/2010 3:15 PM, Andre Juffer wrote:
This provides an overview of the cocoon.request methods:
http://cocoon.apache.org/2.2/blocks/flowscript/1.0/1383_1_1.html
Okay, this looks like a HttpServletRequest object with a few more
methods (like get()). It's too bad the methods are poorly documented:
for instance, get() says that it gets an object from either the
attributes or parameters, but doesn't tell you what the rules are about
when it chooses parameter or attribute.
In either case, that parameter would almost certainly be a /request
parameter/, not a parameter to the function itself.
However, on the cocoon 2.1 site, there is the following:
http://cocoon.apache.org/2.1/userdocs/flow/sitemap.html
That seems to indicate that the proper way to pass parameters from the
sitemap to the flowscript function is like this:
map:match pattern=*
map:call function=equipmentHandler
map:parameter name=method value={request:method} /
/map:call
/map:match
and read them like this:
function equipmentHandler()
{
var request = cocoon.request;
var method = cocoon.parameters.method;
...
See if that works for you.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkyZDQcACgkQ9CaO5/Lv0PB50wCggBRhrbi7JSoDEvsTj4YnHRXf
CggAoJXr6TiRSQBznh131qQeqGJ91m4C
=svV1
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Cocoon 2.2 PUT HTTP request
On 09/21/2010 10:52 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andre,
On 9/21/2010 3:15 PM, Andre Juffer wrote:
This provides an overview of the cocoon.request methods:
http://cocoon.apache.org/2.2/blocks/flowscript/1.0/1383_1_1.html
Okay, this looks like a HttpServletRequest object with a few more
methods (like get()). It's too bad the methods are poorly documented:
for instance, get() says that it gets an object from either the
attributes or parameters, but doesn't tell you what the rules are about
when it chooses parameter or attribute.
In either case, that parameter would almost certainly be a /request
parameter/, not a parameter to the function itself.
However, on the cocoon 2.1 site, there is the following:
http://cocoon.apache.org/2.1/userdocs/flow/sitemap.html
That seems to indicate that the proper way to pass parameters from the
sitemap to the flowscript function is like this:
map:match pattern=*
map:call function=equipmentHandler
map:parameter name=method value={request:method} /
/map:call
/map:match
and read them like this:
function equipmentHandler()
{
var request = cocoon.request;
var method = cocoon.parameters.method;
...
Actually I already tried this before. Did not work either. But please
read my next email I got it working!
See if that works for you.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkyZDQcACgkQ9CaO5/Lv0PB50wCggBRhrbi7JSoDEvsTj4YnHRXf
CggAoJXr6TiRSQBznh131qQeqGJ91m4C
=svV1
-END PGP SIGNATURE-
-
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
Re: Cocoon 2.2 PUT HTTP request
Chris, I got it working now. It is really in the details. I always relied upon a PUT request like http://localhost:/equipment expecting to see the request method set to PUT. In fact, it was always GET. If, however, one employs http://localhost:/equipment/ ---^ (Notice the forward slash at the end!) then the request method is set to PUT. Requests parameters are not available, at least not with Jetty 1.6.7 (and I would assume the same is true for tomcat 6 and 7, did not check). This is what one could expect, as the specification does not require the availability of the request parameters. A GET request with request parameters should also use the forward slash at the end like http://localhost:/equipment/?para1=val1param2=val2 But a GET without parameters like http://localhost:/equipment/123456 is OK (is always interpreted as a GET). Using a POST request instead (and with the forward slash), the request method is POST and all parameters are now available through the getParameter() family of methods ion flowscript. I've not tried any of the other request methods like DELETE. So, this leaves us with the issue with PUT not having the parameters available, but at least the request method is now properly set. I was almost ready to switch to a different framework like https://jersey.dev.java.net/. Almost Thanks, André On 09/21/2010 09:40 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andre, On 9/21/2010 2:04 PM, Andre Juffer wrote: On 09/21/2010 07:38 PM, Christopher Schultz wrote: I find the Cocoon documentation very difficult to navigate. Can you point me to the documentation for calling javascript functions? All I could find was this: http://cocoon.apache.org/2.2/core-modules/core/2.2/844_1_1.html Yeah, it is not that well organized. Have a look at: http://cocoon.apache.org/2.2/blocks/flowscript/1.0/1241_1_1.html In the examples, I see them use code like this: cocoon.request.get(foo) to get a request parameter. get() is not a standard method on HttpServletRequest, so this must be some kind of wrapper around HttpServletRequest. There seems to be nothing about working withmap:parameter elements from the sitemap in the flowscript. :( - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyY/CgACgkQ9CaO5/Lv0PDbZgCfSd98cokDRntfHnLRMkDLduTz 0LAAoKlpGlBDntPj09UTTlyVID7OZkS+ =JCr8 -END PGP SIGNATURE- - 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
Re: Cocoon 2.2 PUT HTTP request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andre, On 9/21/2010 4:26 PM, Andre Juffer wrote: I got it working now. It is really in the details. I always relied upon a PUT request like http://localhost:/equipment expecting to see the request method set to PUT. In fact, it was always GET. If, however, one employs http://localhost:/equipment/ ---^ (Notice the forward slash at the end!) Wow! So, your server was issuing a redirect to the client? That usually only happens when you have something else going on. Is /equipment the context path of your webapp? If so, I think you have to have /something/ after the /equipment, otherwise it's a request for no resource at all. Try confirming (say, with LiveHttpHeaders) that the PUT is being redirected by the server. Requests parameters are not available, at least not with Jetty 1.6.7 (and I would assume the same is true for tomcat 6 and 7, did not check). I've got an enhancement request in for TC 7, and I'm working on a patch. I have it working -- I'm just working on the unit tests and documentation, now. So, this leaves us with the issue with PUT not having the parameters available, but at least the request method is now properly set. I was almost ready to switch to a different framework like https://jersey.dev.java.net/. Almost Well, building a REST service on top of Cocoon seems like a mismatch: Jersey was created explicitly for REST services. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyZMVwACgkQ9CaO5/Lv0PCyiACgmprQv72BM35MiK5G7dN2t/lk GTkAn2O0wSCSvmaVH/R3EUlGUDrZN3Op =heIE -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
