[microsling] script resolution and extension (was: microsling script resolution rewritten)

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

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

> ...(2) I am not sure whether resolving the script with the request
> extension is useful. Rather I would use the "selectors" of the request
> URL (the dot-separated parts between the node path and the extension) as
> further script selectors....

I thought a bit about this, and I suggest instead adding an additional
requestFilter that computes the desired Content-Type for the response,
and stores it in the SlingRequestContext.

The default implementation could just use the extension or selectors
to do this, but at the SlingServlet level you get a clean
"Content-Type=text/html" which tells you what to generate, irrelevant
of the way this was derived from the request.

-Bertrand

Re: [microsling] script resolution and extension (was: microsling script resolution rewritten)

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

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

> ...in any case the request's Accept must
> be obeyed. So if for example the Accept header wants to see text/plain,
> Sling should not set the content type default to image/gif just because
> the extension happens to be gif....

Sure, so it's good to isolate this decision in its own RequestFilter.

-Bertrand

Re: [microsling] script resolution and extension (was: microsling script resolution rewritten)

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

Am Montag, den 15.10.2007, 14:03 +0200 schrieb Bertrand Delacretaz:
> On 10/14/07, Felix Meschberger <fm...@gmail.com> wrote:
> 
> > ...(2) I am not sure whether resolving the script with the request
> > extension is useful. Rather I would use the "selectors" of the request
> > URL (the dot-separated parts between the node path and the extension) as
> > further script selectors....
> 
> I thought a bit about this, and I suggest instead adding an additional
> requestFilter that computes the desired Content-Type for the response,
> and stores it in the SlingRequestContext.
> 
> The default implementation could just use the extension or selectors
> to do this, but at the SlingServlet level you get a clean
> "Content-Type=text/html" which tells you what to generate, irrelevant
> of the way this was derived from the request.

Good idea, this mechanism could probably be used to set the default
content type of the response but in any case the request's Accept must
be obeyed. So if for example the Accept header wants to see text/plain,
Sling should not set the content type default to image/gif just because
the extension happens to be gif.

Regards
Felix