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.
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.
WDYT ?
Or more specifically: Does anyone see a really problematic backwards
compatiblity issue here (except in our integration test cases) ?
Regards
Felix
Sling ignores specified node path when creating content
-------------------------------------------------------
Key: SLING-588
URL: https://issues.apache.org/jira/browse/SLING-588
Project: Sling
Issue Type: Bug
Reporter: Lars Trieloff
Attachments: SLING-588.patch
As described here: http://markmail.org/message/u3be3mpaal4efngj Sling will
ignore the node path specified in the HTTP request when creating contents which
makes it impossible to create nodes with a dot in the node name from a form
post.
