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
