On 23 Sep 2009, at 11:32, Alexander Klimetschek wrote:
On Wed, Sep 23, 2009 at 11:40, Ian Boston <[email protected]> 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.
yes I agree that at c2, after all processing is performed, no resource
is found and, in addition the patch only modifies the behavior of c2.
What I don't see justification for, is parsing the path into
selectors, extensions etc when we have no evidence what is the right
parsing.
The patch adopts a convention as justification for the parsing but
IIUC that convention hasn't been adopted in a,b or c1
IMHO, either the patch should go wide and adopt the convention
throughout or it should avoid imposing a convention leaving it to
things that *might* be able to operate on the non existent resource.
Perhaps this is really ideology over what a URI is, in which case I am
happy to adopt any consistent convention.
Ian
BTW, my concern is not driven by code outside Sling that I will have
to change, I am 100% ok with making those changes regardless of the
outcome here. Progress even in API related behavior is vital.
Regards,
Alex
--
Alexander Klimetschek
[email protected]
