You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Felix Meschberger <fm...@gmail.com> on 2007/10/17 09:17:12 UTC
Re: [jira] Commented: (SLING-60) URI path split is content
dependent
I completely agree with respect to not using a Filter for
ResourceResolution. Lets make the ResourceResolver a service called by
the SlingRequestContext on demand (btw, the SlingRequestContext must
then probably have a reference to the request, right ?).
Regards
Felix
Am Mittwoch, den 17.10.2007, 09:11 +0200 schrieb Bertrand Delacretaz:
> On 10/17/07, Carsten Ziegeler <cz...@apache.org> wrote:
> > Could we please discuss things in the mailing list and not in Jira...
>
> Sure, let me restate what I said in JIRA-60 here:
>
> I agree with what Felix says in JIRA-60, about the RequestPathInfo
> (selectors, extension, suffix, etc) being dependent on the way the
> Resource is resolved. So the current microsling
> SlingRequestPathInfoParser is wrong in its current state.
>
> But I'm not sure if resolving the Resource in a Filter is the best
> idea: how about making the ResourceResolver a first-class Sling API
> citizen instead, and calling that from the SlingRequestContext
> on-demand, when the Resource of the RequestPathInfo is accessed?
>
> This might make it easier to make the ResourceResolver a plugin (in
> Sling OSGi mostly), and might also make the code clearer to follow?
>
> I think Filters are good for either manipulating the Request before
> processing it, or enhancing the Request attributes with "small" things
> that are not always needed, like the detected Locale for example.
>
> But something as fundamental as finding the Resource to act on (and
> computing the RequestPathInfo) should not be "hidden" in a Filter,
> IMHO.
>
> -Bertrand
Re: [jira] Commented: (SLING-60) URI path split is content dependent
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/17/07, Felix Meschberger <fm...@gmail.com> wrote:
> ...Lets make the ResourceResolver a service called by
> the SlingRequestContext on demand...
cool
> ...btw, the SlingRequestContext must
> then probably have a reference to the request, right ?)....
Yes, agreed.
-Bertrand