Re: [microsling] SlingServlet interface, HTTP methods (was: microsling script resolution rewritten)
Hi guys, > I agree, that we might want to wait for a real-life request. > On the other hand it is not only the end-users fault if not the correct > methods could be used, though browsers are probably the major number of > culprits. Many times it is just a question of firewall limitation which > can by no means be circumvented by the casual user on the internet ... I agree, aswell. Generally, I guess what I would be excited to use from a microsling user perspective is: (a) a flexible and very easily extensible GET that does all my different renditions of a content node on the server (b) a clean PUT and DELETE that operates as expected, which is probably triggered through some XHR based js lib in the browser. (c) a functionally powerful POST that (amongst other things) allows me to trigger any content repository modification through a straight html-form in a browser. Generally, this means that as a user I am less interested in tweaking the "writing" mechanisms to the repository, since they are sufficiently simple and complete, while the rendering/presentation is very user and usecase specific. I would personally stay away from any of the mentioned "HTTP method simulation" techniques (until requested). Personally I would assume that there are requirements such as dealing versioning operations or batching up multiple modifications that (short of implementing WebDAV and its ugly cousins) would go into the "powerful" ootb POST handling. Personally I could see a powerful POST handling to be very similar to what Bertrand and I use in http://www.day.com/maven/rjax/ Thoughts? regards, david
Re: [microsling] SlingServlet interface, HTTP methods (was: microsling script resolution rewritten)
I agree, that we might want to wait for a real-life request. On the other hand it is not only the end-users fault if not the correct methods could be used, though browsers are probably the major number of culprits. Many times it is just a question of firewall limitation which can by no means be circumvented by the casual user on the internet ... Regards Felix Am Dienstag, den 16.10.2007, 10:47 -0700 schrieb Roy T. Fielding: > On Oct 16, 2007, at 1:18 AM, Bertrand Delacretaz wrote: > > > On 10/15/07, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > > > >> ...We could for example define that adding a "slingMethod=PUT" > >> parameter > >> to the request causes SlingServlet.doPut to be called instead of > >> doPost > > > > To clarify, note that I meant this for the POST method only, this > > should *not* be done with GET or HEAD. And we're still discussing if > > this should be done at all, see the "Actions (methods) must not appear > > in URIs" thread started by Roy. > > Unless you have an immediate customer need for it, we should not. > That is the kind of thing I would only do in combination with > a very specific user agent string, such that they would see their > bug when they tested newer versions of the user agent (at least > until they remove the restrictions from the browser setting of > header fields). > > Roy >
Re: [microsling] SlingServlet interface, HTTP methods (was: microsling script resolution rewritten)
On Oct 16, 2007, at 1:18 AM, Bertrand Delacretaz wrote: On 10/15/07, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: ...We could for example define that adding a "slingMethod=PUT" parameter to the request causes SlingServlet.doPut to be called instead of doPost To clarify, note that I meant this for the POST method only, this should *not* be done with GET or HEAD. And we're still discussing if this should be done at all, see the "Actions (methods) must not appear in URIs" thread started by Roy. Unless you have an immediate customer need for it, we should not. That is the kind of thing I would only do in combination with a very specific user agent string, such that they would see their bug when they tested newer versions of the user agent (at least until they remove the restrictions from the browser setting of header fields). Roy
Re: [microsling] SlingServlet interface, HTTP methods (was: microsling script resolution rewritten)
Hi, On 10/15/07, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > To handle additional HTTP methods, we can always keep the service() > method, maybe renamed to doOtherHttpMethod(), and call it for HTTP > methods which are not covered by the SlingServlet's doX() methods. This is one of the reasons why I don't really see the point of coming up with our own Servlet interface instead of using the standard HttpServlet base class or our own SlingServlet subclass. HttpServlet.service() already has all the normal dispatch rules, and if needed we could just extend the method in a SlingServlet subclass. BR, Jukka Zitting
Re: [microsling] SlingServlet interface, HTTP methods (was: microsling script resolution rewritten)
On 10/15/07, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > ...We could for example define that adding a "slingMethod=PUT" parameter > to the request causes SlingServlet.doPut to be called instead of > doPost To clarify, note that I meant this for the POST method only, this should *not* be done with GET or HEAD. And we're still discussing if this should be done at all, see the "Actions (methods) must not appear in URIs" thread started by Roy. -Bertrand
Re: [microsling] SlingServlet interface, HTTP methods (was: microsling script resolution rewritten)
Am Montag, den 15.10.2007, 14:00 +0200 schrieb Bertrand Delacretaz: > What I like about the doGet, doPost, doPut, etc.. methods in the > current microsling SlingServlet interface is that they help people > think in terms of HTTP methods. Sounds reasonable indeed. > We could for example define that adding a "slingMethod=PUT" parameter > to the request causes SlingServlet.doPut to be called instead of > doPost. Sling (and microsling) could provide the requested method with a Request wrapper overwriting the getMethod method returning the parameter overwrite instead of the actuall method. > To handle additional HTTP methods, we can always keep the service() > method, maybe renamed to doOtherHttpMethod(), and call it for HTTP > methods which are not covered by the SlingServlet's doX() methods. How about doGeneric() ? And then how about mimiking the way Servlet API HttpServlet does this (except that we would call doGeneric (or whatever) for any non-standard methods. The idea mainly is to provide default implementations for the HEAD, TRACE and OPTIONS method. Yet, the SlingServlet is something else than a script handler. If we resolve the resource type to some .xxx script, it would probably not be worth it to again check the method to call the appropriate doXXX method because the script itself will know how to handle the correct method and not the ScriptHandler evaluating the script. There is IMHO no reason to prevent a JavaScript script from hanlding POST methods. With respect to the "slingMethod" parameter overwriting the actual request Method: This may probably be implemented by a Request wrapper overwriting the getMethod method returning the parameter overwrite instead of the actuall method. We probably may need both: The SlingServlet (probably not in microsling) and an interface for script handlers. Regards Felix