|
View:
New views
4 Messages
—
Rating Filter:
Alert me
|
|
|
RESTful controlsI am just getting into this so excuse my ignorance.
I fully understand and use the new URLBinding in 1.5 and love it. I am trying to find a way to redirect control based on the HTTP request type (PUT DELETE ...). I want to be able to have an action mapping like /person which maps to the PersonActionBean which has all for the available actions. What would be the best way to accomplish this in stripes? Nathan ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Stripes-users mailing list Stripes-users@... https://lists.sourceforge.net/lists/listinfo/stripes-users |
|
|
Re: RESTful controlsI would probably do something like this in a base class and let
subclasses override the Java methods that correspond to the HTTP
methods they want to support.
protected RuntimeException getException(String method) { return new UnsupportedOperationException("Method " + method + " is not supported by " + getClass()); } @DefaultHandler public Resolution execute() { String method = getContext().getRequest().getMethod(); if ("GET".equalsIgnoreCase(method)) { return GET(); } else if ("POST".equalsIgnoreCase(method)) { return POST(); } else if ("PUT".equalsIgnoreCase(method)) { return PUT(); } else if ("DELETE".equalsIgnoreCase(method)) { return DELETE(); } else { throw getException(method); } } protected Resolution GET() { throw getException(getContext().getRequest().getMethod()); } protected Resolution POST() { throw getException(getContext().getRequest().getMethod()); } protected Resolution PUT() { throw getException(getContext().getRequest().getMethod()); } protected Resolution DELETE() { throw getException(getContext().getRequest().getMethod()); } On Thu, Jul 3, 2008 at 11:55 AM, Nathan Maves <nathan.maves@...> wrote: I am just getting into this so excuse my ignorance. -- Ben Gunter ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Stripes-users mailing list Stripes-users@... https://lists.sourceforge.net/lists/listinfo/stripes-users |
|
|
Re: RESTful controlsOn 03-07-2008 at 13:58, Ben Gunter wrote:
> I would probably do something like this in a base class and let subclasses > override the Java methods that correspond to the HTTP methods they want to > support. > > protected RuntimeException getException(String method) { > return new UnsupportedOperationException("Method " + method + " is > not supported by " > + getClass()); > } > > @DefaultHandler > public Resolution execute() { > String method = getContext().getRequest().getMethod(); > if ("GET".equalsIgnoreCase(method)) { > return GET(); > } else if ("POST".equalsIgnoreCase(method)) { > return POST(); > } else if ("PUT".equalsIgnoreCase(method)) { > return PUT(); > } else if ("DELETE".equalsIgnoreCase(method)) { > return DELETE(); > } else { > throw getException(method); > } > } For GET and POST this will work. However, Stripes does not call the ActionBean for the other request methods. So PUT and DELETE will not work. I assume this is because the HTML specification only allows the use of the GET and POST HTTP request methods. To change this, we'd need several changes: - Binding and validation must now take into account that the request body doesn't contain input parameters (like for a POST request), but a binary blob that is to be put somewhere. Or alternatively, the InputStream of the request is left alone so the programmer can read the request himself (which the ActionBeanContext was supposed to abstract away from). - The DispatcherServlet must re-implement the service() method, to detect the request methods HEAD, OPTIONS and TRACE, and direct them to the appropriate handler in HttpServlet. Other calls ultimately redirect to doPost(...), like GET and POST do mow. All in all, I'm not certain if this can be done cleanly easily. Oscar -- ,-_ So I believe [my version of the truth] until a voice on high /() ) says something different. And even then, I'll check to make (__ ( sure somebody didn't slip me some really interesting mushrooms =/ () -- just in case. -- Dark Paladin ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Stripes-users mailing list Stripes-users@... https://lists.sourceforge.net/lists/listinfo/stripes-users |
|
|
Re: RESTful controlsOn Thu, Jul 3, 2008 at 2:54 PM, Oscar Westra van Holthe - Kind <kindop@...> wrote:
Both good points. I believe for a POST request, the input stream will only be read if the content type is either application/x-www-form-urlencoded (by the container) or multipart/form-data (by a multipart wrapper via Stripes). If you use a content type other than those two you should be OK. As for the second point, you could subclass DispatcherServlet and override service(..) to call doPost(..) in all cases. -Ben ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Stripes-users mailing list Stripes-users@... https://lists.sourceforge.net/lists/listinfo/stripes-users |
| Free Forum Powered by Nabble | Forum Help |