On Wed, Sep 23, 2009 at 11:40, Ian Boston <i...@tfd.co.uk> wrote: > IMHO this comes down to if you believe that the resolution of the resource > should be based on parsing the URI path alone, or should be informed by the > existence of a real resource in the content system. > > At the moment most resources in Sling derive the fields of the Resource > object from the real resources, NonExistentResource is one of the exceptions > since it has no resource to inform it.
Exactly. And my argument is that this case is a) special, because no resource present that could be mistakenly "missed" or incorrectly addressed through another extension and b) it's obvious to the API user / Sling developer through the special resource type. Note that before Sling comes up with a non-existent resource, it has already checked for any longest-matching resource to be present. Because there is none, the non-existent resource is created and then the path info is parsed. Thus the path info could never match any existing resource. > Applying the patch resolved the inconsistency but generates a deeper and > more fundamental inconsistency that if also resolved would not allow > resources to have extensions in the content system (ie /content/readme.doc > would not be a valid resource name since parsing by path alone would make > the resource /content/readme ) This is not the case. As noted above, the path info parsing for non-existent resources that the patch introduces is only applied *after* Sling searched for resources in its standard way. Thus a /content/readme.doc would always be found before something like /content/readme.doc.whatever as a non-existent resource could ever be set by Sling. > On that basis I am of the opinion that the current behavior is consistent > with Resource resolution being based on real resources and so the patch > should not be applied. > > You will notice I haven't "voted", as I am prepared to be persuaded that my > assumptions and conclusions are incorrect. I assume you thought that this patch will change the general resource resolution behavior to cut off the resource path at the first dot. This is not the case. This is how it looks like: a) sling gets request with uri, starts searching for the longest matching resource (IIRC cutting off at the last dot first) b) if nothing is found, this is repeated by cutting off at the second-last dot, etc. c1) resource found: use the given resource path and derive selectors, extensions etc. from the rest of the request uri after the resource path c2) no resource found: create a NonExistingResource and parse selectors, extensions etc. after the first dot found in the request path For c2) this means there cannot be a resource at the "virtual" resource path, or any other part of the rest the full URI. Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
