On Mon, Jul 6, 2009 at 3:29 PM, Bertrand Delacretaz<[email protected]> wrote: > On Mon, Jul 6, 2009 at 2:13 PM, Ian Boston<[email protected]> wrote: >> On 6 Jul 2009, at 11:01, Alexander Klimetschek wrote: >>> ...See this (still open) bug with a patch to add selector support: >>> https://issues.apache.org/jira/browse/SLING-864 >> >> I see, same issue >> I guess since its been there since 2.0.2, its not scheduled to be applied ? > > I had a look, tested it and I think we should apply SLING-864, anyone > opposed to that?
>From my side an obvious +1. The main "issue" was that this might not be backwards-compatible and that it is not clear what is the path, what are selectors, etc. For existing resources, the longest-matching path is used and the rest (if there is a dot) is the set of selectors + extension. To avoid problems, we simply take the full path as the resource path, but additionally parse selectors to make script resolution more versatile. As an example: request = /content/some/path/foo.bar.html will give (if nothing exists at /content/some/path/*): sling:nonexistent with path = /content/some/path/foo.bar.html selectors = [bar] extension = [html] Thus servlets registered for such a selector on a nonexistent resource have to know that the resource path will be the full path, including selectors and extension (and suffix maybe). It also makes it hard to properly create resources with dots in it: a request to /content/foo.bar/more/path.selector.ext will take bar/more/path and selector as selectors. Thinking about this, we should at least improve the javadoc of the NonExistentResource to make this clear. Regards, Alex -- Alexander Klimetschek [email protected]
