On 8/4/08, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Hi all, > > After following this discussion, I fear we are missing some facts. Let > me recount them here: > > (1) Not (only) the SlingPostServlet treats existing and > non-existing resources differently. Sling's resource > resolver right from the start does this. > > (2) Handling existing and non-existing resources differently > is part of the game of finding out about the request. > There is just nothing to be found out about a non-existing > resource (except its non-existence). > > (3) I think different handling in SlingPostServlet is wrong > because SlingPostServlet has no way of guessing what the > intentions of the programmers are. Rather the programmer > must be careful enough to clearly declare his intentions > and SlingPostServlet must be flexible enough to cope with > these requirements. This particularly means to _not_ apply > any "hidden" wizardry like breaking a resource path apart. > > > To illustrate the points about the system not being able to guess the > intentions of a programmer: Consider the resource resolver tries to > resolve resources relative to the root and to the /content node such > that for example a request for /a may be resolved to /content/a. > > Now a request is posted to /b with the programmer's intent to have the > resource /content/b created. Given that no resource at /content/b exists > (and neither at /b), the SlingPostServlet would in fact create a > resource /b, which clearly is not the intention of the programmer. > > So here, the programmer has to request for /content/b explicitly and > thus treating existing resources (like /content/a) and non-existing > (like /content/b) resources differently. > > Why should a programmer not be able to do the same with respect to the > selectors and extensions ? > > In fact, there is another point about why SlingPostSerlvet's current > handling of resources is wrong: Consider the name of a resource would > contain a dot, say /foo.bar. You may now POST to /foo.bar.selector.hml > and be sure to modify the resource /foo.bar. Posting to > /foo.baz.selector.html with the intent to create a resource /foo.baz > should it not exist would not work as SlingPostServlet cuts off at the > first dot thus creating resource /foo instead of /foo.baz. > > > So, to come to an end, I think, we can easily document this (new) > behaviour: "For GET/HEAD requests you ask for a presentation (or > representation) of a resource and Sling helps out by using parts of the > URL for the selection of the concrete representation (script). For other > requests (POST, DELETE, ...) you want to modify the resource (and don't > care for the representation) and hence _should_ address the resource > directly without any representational detail such as selectors and > extensions." although i only agree partially, for the sake of clarity and simplicity, i support your suggestion :-) unless anyone has better arguments (david, roy ?)
regards, toby
