On Mon, Jul 6, 2009 at 3:59 PM, Alexander Klimetschek<[email protected]> wrote: > 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. if this is the case, that the fullpath is the resource.getPath(), then
-1 don't use this if the selectors 'catch' they should not be included in the path. rather assume a non-existing resource at /content/some/path/foo. the script can still assemble the full path by concatenating all selectors and extensions. is there a reason why using the full path ? regards, toby > > Thinking about this, we should at least improve the javadoc of the > NonExistentResource to make this clear. > > Regards, > Alex > > -- > Alexander Klimetschek > [email protected] >
