hi guys, i think it is dangerous if we have a different behavior on a POST (that originally should have been a PUT anyway, but due to browser limitations...) based on the existence of a node. I think that would violate the idempotent behavior that we had on the "PUT oriented" operations in the slingpostservlet.
regards, david On Wed, Jul 30, 2008 at 1:46 PM, Tobias Bocanegra <[EMAIL PROTECTED]> wrote: > 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 > -- Visit: http://dev.day.com/ - Day JCR Cup 08 - Win a MacBook Pro
