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
