Re: [microsling] SlingServlet interface, HTTP methods (was: microsling script resolution rewritten)

[Felix Meschberger <fm...@gmail.com>]

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 <method>.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