Hi,
Tobias Bocanegra schrieb:
On 7/30/08, Felix Meschberger <[EMAIL PROTECTED]> wrote:
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...
Yes, but for the moment, the SlingPostServlet is only able to return an
HTML response status. Hence the extension is not used anyway. In other
words: posting as xyz.pdf expecting the response as a PDF is not going
to work anyway.
Also, posting to sample.css to create a node with name sample.css, you
don't expect the answer to be text/css (or so) but probably text/html or
probably even just the status code or a redirect.
In addition, you always have to know the actual resource you are
modifying, only that Sling is able to cut pieces off the name for
existing resource, but not for non-existing resources.
Plus: consider a POST to sample.ext.html and expecting a resource named
sample.ext to be created ....
In the end it boils down to: Are you using the POST with extension to
create new content without extension or not ? If you are using: Would
changing the behaviour create a problem for you ?
A simple use-case could convince us to consider other options ...
Regards
Felix
