On 10/16/07, Felix Meschberger <[EMAIL PROTECTED]> 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

Reply via email to