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 <[EMAIL PROTECTED]> 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
