On 7/30/08, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Hi, > > all taking this to the list for discussion because Lars it making some > important points. > > Lars Trieloff (JIRA) schrieb: > > > If you could decide for a way of fixing the NPE, I would be glad > > > > to have a working workaround. (and close this bug) However I still > > think it is quite easy to find out which case the servlet is dealing > > with. As the user is free to specify the action of the form, he can > > post to /some/sample if he wants no dot and /some/sample.html if he > > wants a dot. > > > > > Speaking more broadly we are increasingly introducing "tricks", > > > > special cases and magic post parameters to deal with a very specific > > use case "most of the times in a CMS or such" while ignoring the needs > > of other use cases like DAM, Blog, Wiki, social networking, forum, > > online shop, podcast, file sharing and other content-centric web > > applications. Having a RESTful web application framework implies in > > my opinion to respect concepts like Resource, Representation, URI > > and to avoid RPC-like interaction if not necessary. > > I agree and thinking about it the SlingPostServlet is more about modifying > (create, update, delete) content and less about content representation. As > such the URL fired at the SlingPostServlet should probably be more treated > as the actual path than it is today. > > The actual code, which does this is buried in the > ModifyOperation.getItemPath method, which tries to locate the item to work > on from the resource. For an existing resource, there is nothing much to be > done, as we have the item through the resource. > > For a non-existing resource, the resource path, contains the full path from > the URL (actually it is ServletRequest.getPathInfo()) including anything > which might be interpreted as selectors and extensions and even suffix. The > idea of this was, that the SlingPostServlet might redirect to this URL after > the update. > > Now, in the meantime we have applied various changes to the > SlingPostServlet, which influence the creation of the name of a node to > create: > > * :name and :nameHint to handle how names are generated > in the case of Slash-Star request (trailing / or /*) > * :redirect to indicate whether to redirect to the modified > or created node after the request. > > Taking all this into account, I come to agree with Lars, that the > SlingPostSerlvet should treat the resource path of a non-existing resource > (to be created) as is without modification. i don't think that this is a good idea. otherwise you would need to know on the client if a resource already exists or not. ii find it very dangerous if the resolution is not symmetric.
IMO, with the extension, you choose the type of response you want. eg, with .json you get a json response, with .html you get a html response. etc... > We still have to deal with the / and /* suffixes, but we do not cut off any > extensions any more from the path. > > In the case of a redirect, the :redirect parameter could just be set with > *.selectors.ext to redirect to the newly create resource with selectors and > extensions, where the SlingPostServlet replaces "*" with the actual location > URL of it. regards, toby
