Anyone opposed to applying SLING-864? (was: Selectors on non existent resources)

[Bertrand Delacretaz <bd...@apache.org>]

On Mon, Jul 6, 2009 at 2:13 PM, Ian Boston<ie...@tfd.co.uk> 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?

-Bertrand

Re: Anyone opposed to applying SLING-864? (was: Selectors on non existent resources)

[Alexander Klimetschek <ak...@day.com>]

On Mon, Jul 6, 2009 at 6:20 PM, Tobias Bocanegra<tr...@day.com> wrote:
> 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 ?

The reason was backwards compatibility: existing serlvets registered
for nonexistent resources would use the path (and obviously ignore the
rest of the path info, since it's always empty). Not changing that
would keep them working.

Note that this case is distinctively marked: through the
sling:nonexistent resource type (and all the other differences that
come up when a resource does not exist yet). Therefore a special
handling is IMHO ok.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: Anyone opposed to applying SLING-864? (was: Selectors on non existent resources)

[Tobias Bocanegra <tr...@day.com>]

On Mon, Jul 6, 2009 at 3:59 PM, Alexander Klimetschek<ak...@day.com> wrote:
> On Mon, Jul 6, 2009 at 3:29 PM, Bertrand
> Delacretaz<bd...@apache.org> wrote:
>> On Mon, Jul 6, 2009 at 2:13 PM, Ian Boston<ie...@tfd.co.uk> 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
> alexander.klimetschek@day.com
>

Re: Anyone opposed to applying SLING-864? (was: Selectors on non existent resources)

[Alexander Klimetschek <ak...@day.com>]

On Mon, Jul 6, 2009 at 3:29 PM, Bertrand
Delacretaz<bd...@apache.org> wrote:
> On Mon, Jul 6, 2009 at 2:13 PM, Ian Boston<ie...@tfd.co.uk> 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
alexander.klimetschek@day.com