You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@sling.apache.org by Felix Meschberger <fm...@gmail.com> on 2008/07/30 12:31:15 UTC

SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)

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.
>

Re: SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)

Posted by Lars Trieloff <lt...@day.com>.

Hi Toby,

On Wed, Jul 30, 2008 at 1:46 PM, Tobias Bocanegra
<to...@day.com>wrote:

>
> 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...
>
>
I think selectors and extensions are a very elegant way to indicate what
representation you want to get, but I think they are not necessary for POST,
PUT and DELETE requests as we have a much richer way of communicating with
the server here. We can send an accept header to indicate what content we
expect and we can also send a Content-Type header to tell the server what
type of content we are sending. This allows us to send XML and get a JSON
confirmation or send URL-encoded formdata and get an HTML response.

One of the main problems I see with cutting off the selectors and extensions
is that the server has less knowledge about what is selector, what is
extension and what is just a dot in the resource name than the client (or
the application developer). So, as Felix said, the developer can easily use
the base name of the resource to be specific, but the server cannot find out
what the developer intended the base name to be.

regards,

Lars

Re: SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)

Posted by Felix Meschberger <fm...@gmail.com>.

Hi,

Tobias Bocanegra schrieb:
> On 8/3/08, Felix Meschberger <fm...@gmail.com> wrote:
>> Hi,
>>
>>  Tobias Bocanegra schrieb:
>>
>>>>  Not necessarily. The HTTP spec mentions headers explicitly for content
>>>> negotiation
>>>>
>> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html)
>>>> and there might be enough cases where a resource (!) happens to have a
>> name
>>>> ending with .html without implying that it is actually HTML. The server
>>>> selects the representation that is being sent and the server determines
>> how
>>>> to value headers or not.
>>>>
>>> content negotiation is certainly an interesting capability, but IMO
>>> poses a lot of problems. for example, i don't want another
>>> representation of a document (for the same url) just because my
>>> browser locale is different. if the urls are not stable, the documents
>>> can't be cached, which is bad.
>>>
>>  Well, the URLs are stable in that they always select the same resource. But
>> the representation differs and hence the resulting representation is not
>> cacheable.
> ...which is not favorable. at least not for GET requests.

Well, I would say YMMV here, right ? It really depends on the 
application ....

Regards
Felix

Re: SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)

Posted by Tobias Bocanegra <to...@day.com>.

On 8/3/08, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
>  Tobias Bocanegra schrieb:
>
> >
> > >  Not necessarily. The HTTP spec mentions headers explicitly for content
> > > negotiation
> > >
> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html)
> > > and there might be enough cases where a resource (!) happens to have a
> name
> > > ending with .html without implying that it is actually HTML. The server
> > > selects the representation that is being sent and the server determines
> how
> > > to value headers or not.
> > >
> > content negotiation is certainly an interesting capability, but IMO
> > poses a lot of problems. for example, i don't want another
> > representation of a document (for the same url) just because my
> > browser locale is different. if the urls are not stable, the documents
> > can't be cached, which is bad.
> >
>
>  Well, the URLs are stable in that they always select the same resource. But
> the representation differs and hence the resulting representation is not
> cacheable.
...which is not favorable. at least not for GET requests.

>  HTTP provides various ways for the response to be selectively cache in the
> form of the Cache-Control and Vary headers.
>
>  Regards
>  Felix
>

Re: SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)

Posted by Felix Meschberger <fm...@gmail.com>.

Hi,

Tobias Bocanegra schrieb:
>>  Not necessarily. The HTTP spec mentions headers explicitly for content
>> negotiation
>> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html)
>> and there might be enough cases where a resource (!) happens to have a name
>> ending with .html without implying that it is actually HTML. The server
>> selects the representation that is being sent and the server determines how
>> to value headers or not.
> content negotiation is certainly an interesting capability, but IMO
> poses a lot of problems. for example, i don't want another
> representation of a document (for the same url) just because my
> browser locale is different. if the urls are not stable, the documents
> can't be cached, which is bad.

Well, the URLs are stable in that they always select the same resource. 
But the representation differs and hence the resulting representation is 
not cacheable.

HTTP provides various ways for the response to be selectively cache in 
the form of the Cache-Control and Vary headers.

Regards
Felix

Re: SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)

Posted by Felix Meschberger <fm...@gmail.com>.

Hi,

Tobias Bocanegra schrieb:
> if you're talking about always addressing the 'resource' in a POST
> request, then there is another problem, that you can't create any
> selector, or extension servlets anymore.

Well, actually Sling ignores selectors and extensions completely when 
selecting scripts for non-HEAD/GET requests.

So, whether you directly address the existing resource or add any 
selectors and extensions in your POST request makes no difference in the 
selection of the script used.

Regards
Felix

Re: SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)

Posted by Michael Marth <mm...@day.com>.

Hi Felix, Lars,

thanks for the help. I will give it a try.

Yet, I still wonder why we chose to ignore selectors and extensions on
POSTs. It appears inconsistent to me that we have these mechanisms that work
beautifully for GET requests, but on POSTs they don't.
Actually, before looking into the docu and asking here I spent quite some
time just trying to POST to a script with a selector because I naturally
assumed that this would work.
Maybe there is a good reason why POSTs with selectors are a bad idea, but
otherwise I suggest to re-consider them.
WDYT?

Michael



You can help yourself with a servlet which you write for your blog post
> resource type handling POST requests.
>
> In addition your servlet would implement the OptingServlet interface,
> which has the accepts(SlingHttpServletRequest) method. In this method
> you check whether the POST request is a Trackback request or not. If the
> request is a simple update POST, just return false and your servlet will
> be ignored.
>
> If the POST request is a Trackback request, return true and your servlet
> will be called to handle the POST request and the default
> SlingPostServlet will not be called.






-- 
Michael Marth | Day JCR Cup 08 | Win a MacBook Pro: http://dev.day.com/

Re: SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)

Posted by Felix Meschberger <fm...@gmail.com>.

Hi Michael,

Michael Marth schrieb:
> Hi Felix,
> 
> I have a question about that:
> 
> 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."
>>
> 
> I would like to implement two different POST features on one node. As
> always, a blog example :) The nodes are blog posts, one feature is posting
> reader comments, the second feature is trackbacks (which come along as POST
> requests from other blogs).
> 
> For the comments I am OK with the default behavior (I do not want to
> overwrite POST.esp). For the trackback feature I need to implement a custom
> behavior (as specified or rather agreed upon by the different blog systems).
> How could I construct a URL that would make it possible to distinguish the
> two POSTs if there are no selectors?

You can help yourself with a servlet which you write for your blog post
resource type handling POST requests.

In addition your servlet would implement the OptingServlet interface,
which has the accepts(SlingHttpServletRequest) method. In this method
you check whether the POST request is a Trackback request or not. If the
request is a simple update POST, just return false and your servlet will
be ignored.

If the POST request is a Trackback request, return true and your servlet
will be called to handle the POST request and the default
SlingPostServlet will not be called.

> 
> Related to this: trackback POSTs are supposed to return an xml document
> containing success or error messages. So in my understanding of Sling's
> handling of extensions for GET requests the URL for trackback POSTs should
> end in .xml. You might say that there is no problem, because Sling ignores
> the extension anyway, so it might as well be .xml, but it seems a bit
> inconsistent to me. I think a POST to /foo.xml should return xml and a POST
> to /foo.html should return html

Agreed. There is an issue actually deailing with this problem.

There is of course a subtle point: the SlingPostServlet actually returns
an XHTML response, though marked as text/html (which only half-way, what
you want). Nevertheless it is correct XML.


Hope this helps.

Regards
Felix

Re: SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)

Posted by Lars Trieloff <lt...@day.com>.

Hi Michael,

I think you should post to /blogentry/comments/ regardless if it is a
trackback or a comment, because the goal is to create a new node below
comments. I fear this means you have to override POST.esp and add a
hidden field requesting HTML output, because Trackback does not
require sending a proper Accept header and there is no easy way to
override the default response type for a specific path that I know of.

regards,

Lars

On Thu, Sep 18, 2008 at 11:21 AM, Michael Marth <mm...@day.com> wrote:
> Hi Felix,
>
> I have a question about that:
>
> 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."
>>
>
> I would like to implement two different POST features on one node. As
> always, a blog example :) The nodes are blog posts, one feature is posting
> reader comments, the second feature is trackbacks (which come along as POST
> requests from other blogs).
>
> For the comments I am OK with the default behavior (I do not want to
> overwrite POST.esp). For the trackback feature I need to implement a custom
> behavior (as specified or rather agreed upon by the different blog systems).
> How could I construct a URL that would make it possible to distinguish the
> two POSTs if there are no selectors?
>
> Related to this: trackback POSTs are supposed to return an xml document
> containing success or error messages. So in my understanding of Sling's
> handling of extensions for GET requests the URL for trackback POSTs should
> end in .xml. You might say that there is no problem, because Sling ignores
> the extension anyway, so it might as well be .xml, but it seems a bit
> inconsistent to me. I think a POST to /foo.xml should return xml and a POST
> to /foo.html should return html
>
> Cheers
> Michael
>
> --
> Michael Marth | Day JCR Cup 08 | Win a MacBook Pro: http://dev.day.com/
>

Re: SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)

Posted by Michael Marth <mm...@day.com>.

Hi Felix,

I have a question about that:

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."
>

I would like to implement two different POST features on one node. As
always, a blog example :) The nodes are blog posts, one feature is posting
reader comments, the second feature is trackbacks (which come along as POST
requests from other blogs).

For the comments I am OK with the default behavior (I do not want to
overwrite POST.esp). For the trackback feature I need to implement a custom
behavior (as specified or rather agreed upon by the different blog systems).
How could I construct a URL that would make it possible to distinguish the
two POSTs if there are no selectors?

Related to this: trackback POSTs are supposed to return an xml document
containing success or error messages. So in my understanding of Sling's
handling of extensions for GET requests the URL for trackback POSTs should
end in .xml. You might say that there is no problem, because Sling ignores
the extension anyway, so it might as well be .xml, but it seems a bit
inconsistent to me. I think a POST to /foo.xml should return xml and a POST
to /foo.html should return html

Cheers
Michael

-- 
Michael Marth | Day JCR Cup 08 | Win a MacBook Pro: http://dev.day.com/

Re: SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)

Posted by Tobias Bocanegra <to...@day.com>.

On 8/4/08, Felix Meschberger <fm...@gmail.com> 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

Re: SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)

Posted by Felix Meschberger <fm...@gmail.com>.

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."


Regards
Felix

Re: SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)

Posted by Tobias Bocanegra <to...@day.com>.

On 8/1/08, Lars Trieloff <lt...@day.com> wrote:
> Hi,
>
>
>  > >  Not necessarily. The HTTP spec mentions headers explicitly for content
>  > > negotiation
>  > > (http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html)
>  > > and there might be enough cases where a resource (!) happens to have a
>  > name
>  > > ending with .html without implying that it is actually HTML. The server
>  > > selects the representation that is being sent and the server determines
>  > how
>  > > to value headers or not.
>  > content negotiation is certainly an interesting capability, but IMO
>  > poses a lot of problems. for example, i don't want another
>  > representation of a document (for the same url) just because my
>  > browser locale is different. if the urls are not stable, the documents
>  > can't be cached, which is bad.
>
>
>
> Correct, but we are talking about POST, PUT and DELETE requests that are not
>  being cached, so that does not matter.
>
>
>
>  > > > it's very logical, that a foo.html and foo.pdf are different
>  > > > representations of the resource foo.
>  > > >
>  > >
>  > >  Only if you forbid having foo.pdf and foo.html as two different
>  > resources
>  > > in the same path. In that case you would have foo.pdf.html and
>  > foo.html.pdf
>  > > and foo.html.html and foo.pdf.pdf.
>  > which i would find very confusing.
>
>
>
> Then we should forbid JCR nodes with a dot in the name. This would mean
>  there are certain applications, where I cannot use Sling anymore, for
>  instance because it is impossible to get an HTML preview of a PDF or an XML
>  with extracted XMP metadata for a JPEG, but it might be less confusing. I
>  wonder how you could fulfill anything except a narrow set of requirements
>  with these restrictions.
>
>
>
>  > >  I have read this before, but I still do not understand why. You mention
>  > not
>  > > a single real use case that would be broken through my proposal.
>  > as i said, i fear problems if non-existent and existent resources are
>  > treated differently.
>
>
>
> What are the problems that you fear? Fear, uncertainty and doubt are no good
>  basis to brush away my valid requests for a broken behavior.
>
>  Furthermore, we are not treating existent and non-existent resources
>  differently. You POST, PUT, DELETE to the base URL of the resource,  you GET
>  from the base URL plus selectors and extensions. This is not treating
>  existent and non-existent resources differently, it is treating GET requests
>  differently, which is a good thing and something we are doing anyway (or
>  where is POST.html.esp)
but the patch in your jira issue treats them differently.

if you're talking about always addressing the 'resource' in a POST
request, then there is another problem, that you can't create any
selector, or extension servlets anymore.

regards, toby

Re: SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)

Posted by Lars Trieloff <lt...@day.com>.

Hi,

> >  Not necessarily. The HTTP spec mentions headers explicitly for content
> > negotiation
> > (http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html)
> > and there might be enough cases where a resource (!) happens to have a
> name
> > ending with .html without implying that it is actually HTML. The server
> > selects the representation that is being sent and the server determines
> how
> > to value headers or not.
> content negotiation is certainly an interesting capability, but IMO
> poses a lot of problems. for example, i don't want another
> representation of a document (for the same url) just because my
> browser locale is different. if the urls are not stable, the documents
> can't be cached, which is bad.


Correct, but we are talking about POST, PUT and DELETE requests that are not
being cached, so that does not matter.


> > > it's very logical, that a foo.html and foo.pdf are different
> > > representations of the resource foo.
> > >
> >
> >  Only if you forbid having foo.pdf and foo.html as two different
> resources
> > in the same path. In that case you would have foo.pdf.html and
> foo.html.pdf
> > and foo.html.html and foo.pdf.pdf.
> which i would find very confusing.


Then we should forbid JCR nodes with a dot in the name. This would mean
there are certain applications, where I cannot use Sling anymore, for
instance because it is impossible to get an HTML preview of a PDF or an XML
with extracted XMP metadata for a JPEG, but it might be less confusing. I
wonder how you could fulfill anything except a narrow set of requirements
with these restrictions.


> >  I have read this before, but I still do not understand why. You mention
> not
> > a single real use case that would be broken through my proposal.
> as i said, i fear problems if non-existent and existent resources are
> treated differently.


What are the problems that you fear? Fear, uncertainty and doubt are no good
basis to brush away my valid requests for a broken behavior.

Furthermore, we are not treating existent and non-existent resources
differently. You POST, PUT, DELETE to the base URL of the resource,  you GET
from the base URL plus selectors and extensions. This is not treating
existent and non-existent resources differently, it is treating GET requests
differently, which is a good thing and something we are doing anyway (or
where is POST.html.esp)

regards,

Lars

Re: SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)

Posted by Tobias Bocanegra <to...@day.com>.

hi,

On 7/31/08, Lars Trieloff <lt...@day.com> wrote:
> Hi Toby,
>
>  On Jul 31, 2008, at 21:01 , Tobias Bocanegra wrote:
>
> >
> > >
> > > >
> > > > > Hi,
> > > > > we are not violating the idempotency of the PUT (disguised as a
> POST)
> > > > >
> > > > > 1. POST /foo.bar.html (foo=bar)
> > > > > 2. GET /foo.bar.html
> > > > > 3. POST /foo.bar.html (foo=bar)
> > > > > 4. GET /foo.bar.html
> > > > >
> > > > > If request 1 and 3 are identical, responses 2 and 4 will be
> identical as
> > > > > well.
> > > > >
> > > > does not compute :-)
> > > >
> > > What I meant is: you can post the same request parameters
> (representation)
> > > as often as you like, the resource will have the same state afterwards.
> The
> > > POST has no side-effects and it does not work additive. So it is
> idempotent
> > > and can work as a replacement for a PUT.
> > >
> > yes, but only if the addressing does not change in respect if the
> > resource is present or not.
> >
>
>  David's original point was that cutting off extensions might be necessary
> to preserve the idempotency of the POST request. I have shown that it is not
> necessary.
>
>
> >
> > >
> > > > as far as i understood REST, the url always addresses a representation
> > > > of a resource.
> > > > so when you GET a /foo.html you get for example the HTML
> > > > representation of the resource /foo. if you post to /foo.html, you
> > > > want to update the HTML representation of the resource /foo.
> > > >
> > > The URL locates the resource. What gets transferred is the
> representation.
> > > We are using extensions and selectors only due to limitations of our
> > > browsers that do not allow us to set the Accept header for GET requests
> > > (which would be the proper way of indicating what representation you can
> > > deal with). I think extensions and selectors are a neat workaround, but
> we
> > > should not overuse them were we do not rely on them (e.g. everywhere
> where
> > > we can send request headers or a request entity)
> > >
> >
> > no, the URL (and only the url) locates the representation of the
> > resource, which is in most cases the same, of course.
> >
>
>  URL (Uniform Resource Locator) locate resources in a uniform way. Resources
> and representations are not the same or identical, as they describe
> different concepts. Even if there is only one representation of the resource
> (which is almost never the case with Sling where we have a txt and a json
> representation for every resource).
>
>
> > no matter what
> > headers are set, if i request a .html, i want a HTML document (or i
> > should always get the same, irrespective of the headers).
> >
>
>  Not necessarily. The HTTP spec mentions headers explicitly for content
> negotiation
> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html)
> and there might be enough cases where a resource (!) happens to have a name
> ending with .html without implying that it is actually HTML. The server
> selects the representation that is being sent and the server determines how
> to value headers or not.
content negotiation is certainly an interesting capability, but IMO
poses a lot of problems. for example, i don't want another
representation of a document (for the same url) just because my
browser locale is different. if the urls are not stable, the documents
can't be cached, which is bad.

> > it's very logical, that a foo.html and foo.pdf are different
> > representations of the resource foo.
> >
>
>  Only if you forbid having foo.pdf and foo.html as two different resources
> in the same path. In that case you would have foo.pdf.html and foo.html.pdf
> and foo.html.html and foo.pdf.pdf.
which i would find very confusing.

> > so actually, if i want to change
> > representation independent properties, i need to post to /foo, if i
> > want to change PDF representation properties, e.g.. a watermark, i
> > post to foo.pdf.
> >
>
>  If your representation has distinct properties that can be changed
> individually, you do not have a representation, you have another resource.
> If you want to upload a new thumbnail, you should PUT it to the appropriate
> resource and indicate the content type accordingly.
>
>
> > however, this does not help us here.
> >
> > i suggest to leave the resolution the way it is,
> >
>
>  I have read this before, but I still do not understand why. You mention not
> a single real use case that would be broken through my proposal.
as i said, i fear problems if non-existent and existent resources are
treated differently.

> > and you need to find
> > a workaround for your upload-a-css-file problem
> >
>
>  Thank you very much for your proposal. I did look for workarounds and found
> them cumbersome and inconsistent with the intended RESTful nature of Sling.
> Which was the reason why I proposed to fix it.
>
>
> > (which should be done
> > via webdav anyways :-)
> >
>
>  Unfortunately I have no WebDAV in my browser and it is quite hard to
> convince the browser to PUT the contents of a textarea to an URL.
> Furthermore, the Sling way of expressing a PUT to a non-existing resource
> with a POST does not work, precisely because the POST servlet does something
> the WebDAV servlet will never do: it ignores the resource location the
> client specifies and tries to apply its own rules of finding out what's best
> for me. If this is the case, we should perhaps change the behavior of the
> WebDAV servlet accordingly to make it a bit less surprising.
>
>  regards,
>
>  Lars
>
>
>
> >
> >
> > regards, toby
> >
> >
> > >
> > >
> > >
> > >
> > > > and i think here is the problem, since .css (or .pdf, ...) is treated
> > > >
> > >
> > >
> > > > the same way. in your example, if you want to 'upload' the /foo.css,
> > > >
> > >
> > >
> > > > then in this case, the resource and the representation URL are the
> > > > same: /foo.css. but i don't know how to discover that in a smart way.
> > > > maybe because there is a file parameter pointing to "." ?
> > > >
> > >
> > >
> > >
> > > I think we do not need to be smart here. All we need to do is trust the
> > > client (or the developer) that she is able to correctly locate the
> resource.
> > > Do not use magic that could stab you in the back.
> > >
> > > regards,
> > >
> > >
> > > Lars
> > >
> > >
> > >
> > >
> > > >
> > > > regards, toby
> > > >
> > > >
> > > > > On Wed, Jul 30, 2008 at 1:59 PM, David Nuescheler <da...@day.com>
> > > > >
> > > > wrote:
> > > >
> > > > >
> > > > >
> > > > > > 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
> > > > > > <to...@day.com> wrote:
> > > > > >
> > > > > > > On 7/30/08, Felix Meschberger <fm...@gmail.com> 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
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
>
>

Re: SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)

Posted by Lars Trieloff <lt...@day.com>.

Hi Toby,

On Jul 31, 2008, at 21:01 , Tobias Bocanegra wrote:
>>>> Hi,
>>>> we are not violating the idempotency of the PUT (disguised as a  
>>>> POST)
>>>>
>>>> 1. POST /foo.bar.html (foo=bar)
>>>> 2. GET /foo.bar.html
>>>> 3. POST /foo.bar.html (foo=bar)
>>>> 4. GET /foo.bar.html
>>>>
>>>> If request 1 and 3 are identical, responses 2 and 4 will be  
>>>> identical as
>>>> well.
>>> does not compute :-)
>> What I meant is: you can post the same request parameters  
>> (representation)
>> as often as you like, the resource will have the same state  
>> afterwards. The
>> POST has no side-effects and it does not work additive. So it is  
>> idempotent
>> and can work as a replacement for a PUT.
> yes, but only if the addressing does not change in respect if the
> resource is present or not.

David's original point was that cutting off extensions might be  
necessary to preserve the idempotency of the POST request. I have  
shown that it is not necessary.

>>> as far as i understood REST, the url always addresses a  
>>> representation
>>> of a resource.
>>> so when you GET a /foo.html you get for example the HTML
>>> representation of the resource /foo. if you post to /foo.html, you
>>> want to update the HTML representation of the resource /foo.
>> The URL locates the resource. What gets transferred is the  
>> representation.
>> We are using extensions and selectors only due to limitations of our
>> browsers that do not allow us to set the Accept header for GET  
>> requests
>> (which would be the proper way of indicating what representation  
>> you can
>> deal with). I think extensions and selectors are a neat workaround,  
>> but we
>> should not overuse them were we do not rely on them (e.g.  
>> everywhere where
>> we can send request headers or a request entity)
>
> no, the URL (and only the url) locates the representation of the
> resource, which is in most cases the same, of course.

URL (Uniform Resource Locator) locate resources in a uniform way.  
Resources and representations are not the same or identical, as they  
describe different concepts. Even if there is only one representation  
of the resource (which is almost never the case with Sling where we  
have a txt and a json representation for every resource).

> no matter what
> headers are set, if i request a .html, i want a HTML document (or i
> should always get the same, irrespective of the headers).

Not necessarily. The HTTP spec mentions headers explicitly for content  
negotiation (http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html)  
and there might be enough cases where a resource (!) happens to have a  
name ending with .html without implying that it is actually HTML. The  
server selects the representation that is being sent and the server  
determines how to value headers or not.

> it's very logical, that a foo.html and foo.pdf are different
> representations of the resource foo.

Only if you forbid having foo.pdf and foo.html as two different  
resources in the same path. In that case you would have foo.pdf.html  
and foo.html.pdf and foo.html.html and foo.pdf.pdf.

> so actually, if i want to change
> representation independent properties, i need to post to /foo, if i
> want to change PDF representation properties, e.g.. a watermark, i
> post to foo.pdf.

If your representation has distinct properties that can be changed  
individually, you do not have a representation, you have another  
resource. If you want to upload a new thumbnail, you should PUT it to  
the appropriate resource and indicate the content type accordingly.

> however, this does not help us here.
>
> i suggest to leave the resolution the way it is,

I have read this before, but I still do not understand why. You  
mention not a single real use case that would be broken through my  
proposal.

> and you need to find
> a workaround for your upload-a-css-file problem

Thank you very much for your proposal. I did look for workarounds and  
found them cumbersome and inconsistent with the intended RESTful  
nature of Sling. Which was the reason why I proposed to fix it.

> (which should be done
> via webdav anyways :-)

Unfortunately I have no WebDAV in my browser and it is quite hard to  
convince the browser to PUT the contents of a textarea to an URL.  
Furthermore, the Sling way of expressing a PUT to a non-existing  
resource with a POST does not work, precisely because the POST servlet  
does something the WebDAV servlet will never do: it ignores the  
resource location the client specifies and tries to apply its own  
rules of finding out what's best for me. If this is the case, we  
should perhaps change the behavior of the WebDAV servlet accordingly  
to make it a bit less surprising.

regards,

Lars

>
>
> regards, toby
>
>>
>>
>>
>>> and i think here is the problem, since .css (or .pdf, ...) is  
>>> treated
>>
>>> the same way. in your example, if you want to 'upload' the /foo.css,
>>
>>> then in this case, the resource and the representation URL are the
>>> same: /foo.css. but i don't know how to discover that in a smart  
>>> way.
>>> maybe because there is a file parameter pointing to "." ?
>>
>>
>>
>> I think we do not need to be smart here. All we need to do is trust  
>> the
>> client (or the developer) that she is able to correctly locate the  
>> resource.
>> Do not use magic that could stab you in the back.
>>
>> regards,
>>
>>
>> Lars
>>
>>
>>
>>>
>>> regards, toby
>>>
>>>> On Wed, Jul 30, 2008 at 1:59 PM, David Nuescheler <da...@day.com>
>>> wrote:
>>>>
>>>>> 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
>>>>> <to...@day.com> wrote:
>>>>>> On 7/30/08, Felix Meschberger <fm...@gmail.com> 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
>>>>>
>>>>
>>>
>>

Re: SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)

Posted by Tobias Bocanegra <to...@day.com>.

On 7/31/08, Lars Trieloff <lt...@day.com> wrote:
> Hi Toby,
>
>  On Thu, Jul 31, 2008 at 1:27 PM, Tobias Bocanegra
>
> <to...@day.com>wrote:
>
>
> > On 7/30/08, Lars Trieloff <lt...@day.com> wrote:
>  > > Hi,
>  > >  we are not violating the idempotency of the PUT (disguised as a POST)
>  > >
>  > >  1. POST /foo.bar.html (foo=bar)
>  > >  2. GET /foo.bar.html
>  > >  3. POST /foo.bar.html (foo=bar)
>  > >  4. GET /foo.bar.html
>  > >
>  > >  If request 1 and 3 are identical, responses 2 and 4 will be identical as
>  > >  well.
>  > does not compute :-)
>
>
>
> What I meant is: you can post the same request parameters (representation)
>  as often as you like, the resource will have the same state afterwards. The
>  POST has no side-effects and it does not work additive. So it is idempotent
>  and can work as a replacement for a PUT.
yes, but only if the addressing does not change in respect if the
resource is present or not.

>  > as far as i understood REST, the url always addresses a representation
>  > of a resource.
>  > so when you GET a /foo.html you get for example the HTML
>  > representation of the resource /foo. if you post to /foo.html, you
>  > want to update the HTML representation of the resource /foo.
>
>
>
> The URL locates the resource. What gets transferred is the representation.
>  We are using extensions and selectors only due to limitations of our
>  browsers that do not allow us to set the Accept header for GET requests
>  (which would be the proper way of indicating what representation you can
>  deal with). I think extensions and selectors are a neat workaround, but we
>  should not overuse them were we do not rely on them (e.g. everywhere where
>  we can send request headers or a request entity)

no, the URL (and only the url) locates the representation of the
resource, which is in most cases the same, of course. no matter what
headers are set, if i request a .html, i want a HTML document (or i
should always get the same, irrespective of the headers).

it's very logical, that a foo.html and foo.pdf are different
representations of the resource foo. so actually, if i want to change
representation independent properties, i need to post to /foo, if i
want to change PDF representation properties, e.g.. a watermark, i
post to foo.pdf.

however, this does not help us here.

i suggest to leave the resolution the way it is, and you need to find
a workaround for your upload-a-css-file problem (which should be done
via webdav anyways :-)

regards, toby

>
>
>
>  > and i think here is the problem, since .css (or .pdf, ...) is treated
>
> > the same way. in your example, if you want to 'upload' the /foo.css,
>
> > then in this case, the resource and the representation URL are the
>  > same: /foo.css. but i don't know how to discover that in a smart way.
>  > maybe because there is a file parameter pointing to "." ?
>
>
>
> I think we do not need to be smart here. All we need to do is trust the
>  client (or the developer) that she is able to correctly locate the resource.
>  Do not use magic that could stab you in the back.
>
>  regards,
>
>
>  Lars
>
>
>
>  >
>  > regards, toby
>  >
>  > >  On Wed, Jul 30, 2008 at 1:59 PM, David Nuescheler <da...@day.com>
>  > wrote:
>  > >
>  > >  > 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
>  > >  > <to...@day.com> wrote:
>  > >  > > On 7/30/08, Felix Meschberger <fm...@gmail.com> 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
>  > >  >
>  > >
>  >
>

Re: SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)

Posted by Lars Trieloff <lt...@day.com>.

Hi Toby,

On Thu, Jul 31, 2008 at 1:27 PM, Tobias Bocanegra
<to...@day.com>wrote:

> On 7/30/08, Lars Trieloff <lt...@day.com> wrote:
> > Hi,
> >  we are not violating the idempotency of the PUT (disguised as a POST)
> >
> >  1. POST /foo.bar.html (foo=bar)
> >  2. GET /foo.bar.html
> >  3. POST /foo.bar.html (foo=bar)
> >  4. GET /foo.bar.html
> >
> >  If request 1 and 3 are identical, responses 2 and 4 will be identical as
> >  well.
> does not compute :-)


What I meant is: you can post the same request parameters (representation)
as often as you like, the resource will have the same state afterwards. The
POST has no side-effects and it does not work additive. So it is idempotent
and can work as a replacement for a PUT.


> as far as i understood REST, the url always addresses a representation
> of a resource.
> so when you GET a /foo.html you get for example the HTML
> representation of the resource /foo. if you post to /foo.html, you
> want to update the HTML representation of the resource /foo.


The URL locates the resource. What gets transferred is the representation.
We are using extensions and selectors only due to limitations of our
browsers that do not allow us to set the Accept header for GET requests
(which would be the proper way of indicating what representation you can
deal with). I think extensions and selectors are a neat workaround, but we
should not overuse them were we do not rely on them (e.g. everywhere where
we can send request headers or a request entity)


> and i think here is the problem, since .css (or .pdf, ...) is treated
> the same way. in your example, if you want to 'upload' the /foo.css,
> then in this case, the resource and the representation URL are the
> same: /foo.css. but i don't know how to discover that in a smart way.
> maybe because there is a file parameter pointing to "." ?


I think we do not need to be smart here. All we need to do is trust the
client (or the developer) that she is able to correctly locate the resource.
Do not use magic that could stab you in the back.

regards,

Lars


>
> regards, toby
>
> >  On Wed, Jul 30, 2008 at 1:59 PM, David Nuescheler <da...@day.com>
> wrote:
> >
> >  > 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
> >  > <to...@day.com> wrote:
> >  > > On 7/30/08, Felix Meschberger <fm...@gmail.com> 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
> >  >
> >
>

Re: SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)

Posted by Tobias Bocanegra <to...@day.com>.

On 7/30/08, Lars Trieloff <lt...@day.com> wrote:
> Hi,
>  we are not violating the idempotency of the PUT (disguised as a POST)
>
>  1. POST /foo.bar.html (foo=bar)
>  2. GET /foo.bar.html
>  3. POST /foo.bar.html (foo=bar)
>  4. GET /foo.bar.html
>
>  If request 1 and 3 are identical, responses 2 and 4 will be identical as
>  well.
does not compute :-)

as far as i understood REST, the url always addresses a representation
of a resource.
so when you GET a /foo.html you get for example the HTML
representation of the resource /foo. if you post to /foo.html, you
want to update the HTML representation of the resource /foo.

and i think here is the problem, since .css (or .pdf, ...) is treated
the same way. i your example, if you want to 'upload' the /foo.css,
then in this case, the resource and the representation URL are the
same: /foo.css. but i don't know how to discover that in a smart way.
maybe because there is a file parameter pointing to "." ?

regards, toby

>  On Wed, Jul 30, 2008 at 1:59 PM, David Nuescheler <da...@day.com> wrote:
>
>  > 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
>  > <to...@day.com> wrote:
>  > > On 7/30/08, Felix Meschberger <fm...@gmail.com> 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
>  >
>

Re: SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)

Posted by Lars Trieloff <lt...@day.com>.

Hi,
we are not violating the idempotency of the PUT (disguised as a POST)

1. POST /foo.bar.html (foo=bar)
2. GET /foo.bar.html
3. POST /foo.bar.html (foo=bar)
4. GET /foo.bar.html

If request 1 and 3 are identical, responses 2 and 4 will be identical as
well.

regards,

Lars

On Wed, Jul 30, 2008 at 1:59 PM, David Nuescheler <da...@day.com> wrote:

> 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
> <to...@day.com> wrote:
> > On 7/30/08, Felix Meschberger <fm...@gmail.com> 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
>

Re: SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)

Posted by David Nuescheler <da...@day.com>.

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
<to...@day.com> wrote:
> On 7/30/08, Felix Meschberger <fm...@gmail.com> 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

Re: SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)

Posted by Felix Meschberger <fm...@gmail.com>.

Hi,

Tobias Bocanegra schrieb:
> On 7/30/08, Felix Meschberger <fm...@gmail.com> wrote:
>>
>>  A simple use-case could convince us to consider other options ...
> yes, a simple form, that posts to a resource irrespective if it exists or not:
> 
> <form method="post" action="/foo/bar.html">
> <input type="text" name="title" value="">
> </form>

May be too simple ;-) Because the form could just as well be written as:

<form method="post" action="/foo/bar">
    <input type="text" name="title" value="">
</form>

In fact, this form even clearly indicates directly and exactly what 
content item you are about to modify, without having in mind some Sling 
operations applied to the URL.

Regards
Felix

Re: SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)

Posted by Tobias Bocanegra <to...@day.com>.

On 7/30/08, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
>  Tobias Bocanegra schrieb:
>
> > On 7/30/08, Felix Meschberger <fm...@gmail.com> 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 ...
yes, a simple form, that posts to a resource irrespective if it exists or not:

<form method="post" action="/foo/bar.html">
<input type="text" name="title" value="">
</form>

regards, toby

Re: SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)

Posted by Felix Meschberger <fm...@gmail.com>.

Hi,

Tobias Bocanegra schrieb:
> On 7/30/08, Felix Meschberger <fm...@gmail.com> 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

Re: SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)

Posted by Tobias Bocanegra <to...@day.com>.

On 7/30/08, Felix Meschberger <fm...@gmail.com> 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

Re: SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)

Posted by Bertrand Delacretaz <bd...@apache.org>.

Hi,

On Wed, Jul 30, 2008 at 12:31 PM, Felix Meschberger <fm...@gmail.com> wrote:

> ...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...

Agree with that. and let's see if people who are using Sling at the
application level have a problem with that.

> ...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....

Sounds good.

-Bertrand