microsling: To Servlet or to SlingServlet

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

Hi all,

Currently the SlingServlet is a very simple interface defining doXXX
methods for some HTTP request methods and a canProcess method to ask
whether the SlingServlet is willing to process the request. I think,
this interface is not required as is. I discussed this quickly with
Bertrand yesterday, and we came up with the idea of a SlingGetServlet
and a SlingServlet.

The SlingGetServlet would also provide API for the GET and HEAD methods,
the SlingServlet would add support for the rest of the core HTTP methods
like OPTIONS, TRACE, POST, PUT and DELETE. And finally, an extension of
SlingServlet could add support for more methods, for example a
SlingDAVServlet might add support for WebDAV methods like MKCOL, etc.

While we agree that it is a good idea - also from a educational point of
view - to have such servlets with precanned doXXX methods, we do not
actually agree, where the selection of the doXXX method should be
located.

Bertrand thinks along the ways of the current microsling SlingServlet,
which just has the doXXX methods and some core class in Sling select the
doXXX method based on the request method (and optional method
overwrite).

I think along the lines of the javax.servlet HttpServlet class, which
implements this dispatching in the service method with an important
difference, of course: We would not simply throw on a method not
directly known but dispatch to a doGeneric method, which by default
throws of course.

What is your opinion on this: A separate SlingServlet interface/class
hieararchy or going along the lines of the HttpServlet (yet doing it
better with respect to non-core HTTP methods) ?

Regards
Felix

Re: microsling: To Servlet or to SlingServlet

[Bertrand Delacretaz <bd...@apache.org>]

On 10/16/07, Felix Meschberger <fm...@gmail.com> wrote:

> ...What is your opinion on this: A separate SlingServlet interface/class
> hieararchy or going along the lines of the HttpServlet (yet doing it
> better with respect to non-core HTTP methods) ?...

I tend to agree with you guys about using standard javax HttpServlet
interfaces, but there are two things that I'd like to have, if
possible:

1) GET-only servlets
In your usual webapp, many servlets or presentation scripts only
render content, with no side effects.

Having a distinct servlet type for these might be useful, IMHO, to
help people think in terms of safe vs. unsafe HTTP methods.

But this could simply be a marker interface ("implements GetHeadOnly")
that people can add to their javax HttpServlets. And Sling would make
sure to call such servlets for GET or HEAD methods only.

2) the canProcess(HttpServletRequest) method
I find it useful, in some cases, to be able to ask a servlet if it
wants to process the current request, as opposed to basing the routing
on the URL only: the servlet might base its decision on request
attributes, for example, that have been computed upstream.

But this could also be an additional interface that java HttpServlets
optionally implement.

So I'd be ok to go with javax HttpServlets, also because this makes
(micro)Sling more immediately understandable.

-Bertrand

Re: microsling: To Servlet or to SlingServlet

[Carsten Ziegeler <cz...@apache.org>]

Jukka Zitting wrote:
> Hi,
> 
> On 10/16/07, Felix Meschberger <fm...@gmail.com> wrote:
>> What is your opinion on this: A separate SlingServlet interface/class
>> hieararchy or going along the lines of the HttpServlet (yet doing it
>> better with respect to non-core HTTP methods) ?
> 
> I'd go with HttpServlet, see my previous email on the related thread.
> 
Same here. We could think about adding some fancy annotation based
dispatching later on (like annotation java methods if they implement the
behaviour for an http method etc.).

Carsten

-- 
Carsten Ziegeler
cziegeler@apache.org

Re: microsling: To Servlet or to SlingServlet

[Jukka Zitting <ju...@gmail.com>]

Hi,

On 10/16/07, Felix Meschberger <fm...@gmail.com> wrote:
> What is your opinion on this: A separate SlingServlet interface/class
> hieararchy or going along the lines of the HttpServlet (yet doing it
> better with respect to non-core HTTP methods) ?

I'd go with HttpServlet, see my previous email on the related thread.

BR,

Jukka Zitting