Re: sling examples: sling-generated path

[Felix Meschberger]

Hi Julian,

Julian Reschke schrieb:
> Hi,
> 
> I was just looking at the sling-in-15min tutorial, and came across the
> section "Let Sling generate the path of a newly created node", which
> describes using POST and "*" as last path segment...
> 
> Out of curiosity: why not just POST to the location? That seems to be
> more in sync with how POST is defined in HTTP...

You may POST to the location with a trailing slash to create a new child
resource. The name will be generated automatically, unless the :name
parameter is given. If the :nameHint parameter is set, the value will be
used as a hint for the name to generate. Thus the :nameHint parameter is
probably comparable to the AtomPub "Slug" header.

Full documentation on the default POST support in Sling is available at [1].

Hope this helps.

Regards
Felix

[1]
http://incubator.apache.org/sling/site/manipulating-content-the-slingpostservlet.html

Re: sling examples: sling-generated path

[Felix Meschberger]

Hi,

Bertrand Delacretaz schrieb:
> On Thu, Oct 16, 2008 at 5:14 PM, David Nuescheler <[EMAIL PROTECTED]> wrote:
>> ...anyway, in hind-sight the /xyz/* for the POST is probably not ideal
>> and in my mind should
>> be deprecated in favour of /xyz/ with a trailing slash

While the .../* form is not deprecated, it is actually now called an
"alternative" way to the more natural form with a trailing slash.

Thus POST-ing to /xyz/ is the same as posting to /xyz/*, that is
creating a new resource below /xyz.

> 
> The problem with not using xyz/* is differentiating between create and
> modify operations.
> 
> If a POST to xyz/ always creates a new node under it, how to you
> update a property on xyz itself?

POST-ing to /xyz/ always creates a new child resource and never modifies
the /xyz resource.

Regards
Felix

> 
> Being able to use PUT would be the answer, but browsers don't do that.
> We could have used HTTP headers to make a POST behave like a PUT, but
> I think the magic star is easier to use from browsers, and more
> visible than a HTTP header.
> 
> So my answer is: we currently use xyz/* as a workaround, to
> differentiate between "create" and "modify" when working with today's
> browsers as clients.
> 
> -Bertrand
> 

Re: sling examples: sling-generated path

[Julian Reschke]

David Nuescheler wrote:

for known resources this is the case... and everybody is welcome to do
that.

Sure; in *that* case of course PUT is right...

...and of course that works aswell ;)

except for that it is a pain to impossible to get a browser to do that.
think of file uploads for example...


But those are constrained to a specific content type, right? So I assume 
the POST handler takea care of that as well?



also there is a quite a bit of infrastructure around that strips custom
headers and disallows methods beyond GET and POST. ...but
i am sure that we are all aware of that ;)


Being able to use PUT would be the answer, but browsers don't do that.

Browsers do with XHR; is this required to work with forms? (as you can guess
from that question, I'm a total newbie wrt Sling).

well, as long as you are not dealing with binaries ;)
also the semantics of PUT do not reflect the PATCH style updates.


Aha, so we need PATCH :-)


anyway, in hind-sight the /xyz/* for the POST is probably not ideal
and in my mind should
be deprecated in favour of /xyz/ with a trailing slash.

Yep. That would align it with how adding to collections works in AtomPub.

cool.


BR, Julian

Re: sling examples: sling-generated path

[David Nuescheler]

>> for known resources this is the case... and everybody is welcome to do
>> that.
> Sure; in *that* case of course PUT is right...
...and of course that works aswell ;)

except for that it is a pain to impossible to get a browser to do that.
think of file uploads for example...

also there is a quite a bit of infrastructure around that strips custom
headers and disallows methods beyond GET and POST. ...but
i am sure that we are all aware of that ;)

>> Being able to use PUT would be the answer, but browsers don't do that.
> Browsers do with XHR; is this required to work with forms? (as you can guess
> from that question, I'm a total newbie wrt Sling).
well, as long as you are not dealing with binaries ;)
also the semantics of PUT do not reflect the PATCH style updates.

>> anyway, in hind-sight the /xyz/* for the POST is probably not ideal
>> and in my mind should
>> be deprecated in favour of /xyz/ with a trailing slash.
> Yep. That would align it with how adding to collections works in AtomPub.
cool.

regards,
david

Re: sling examples: sling-generated path

[Julian Reschke]

Julian Reschke wrote:

...

So my answer is: we currently use xyz/* as a workaround, to
differentiate between "create" and "modify" when working with today's
browsers as clients.


One could imagine other ways to hack it into the URL, such as path 
parameters or query parameters...

...


Speaking of which... 
 
makes a proposal for a way to discover that kind of 
POST-for-add-member-URL for WebDAV, but it might be applicable here as 
well (see in particular 
).


BR, Julian

Re: sling examples: sling-generated path

[Julian Reschke]

Bertrand Delacretaz wrote:

On Thu, Oct 16, 2008 at 5:14 PM, David Nuescheler <[EMAIL PROTECTED]> wrote:

...anyway, in hind-sight the /xyz/* for the POST is probably not ideal
and in my mind should
be deprecated in favour of /xyz/ with a trailing slash


The problem with not using xyz/* is differentiating between create and
modify operations.

If a POST to xyz/ always creates a new node under it, how to you
update a property on xyz itself?

Being able to use PUT would be the answer, but browsers don't do that.


Browsers do with XHR; is this required to work with forms? (as you can 
guess from that question, I'm a total newbie wrt Sling).



We could have used HTTP headers to make a POST behave like a PUT, but
I think the magic star is easier to use from browsers, and more
visible than a HTTP header.


It's definitively better than a header.


So my answer is: we currently use xyz/* as a workaround, to
differentiate between "create" and "modify" when working with today's
browsers as clients.


One could imagine other ways to hack it into the URL, such as path 
parameters or query parameters...


BR, Julian

Re: sling examples: sling-generated path

[Julian Reschke]

David Nuescheler wrote:

Out of curiosity: why not just POST to the location? That seems to be more
in sync with how POST is defined in HTTP...

for known resources this is the case... and everybody is welcome to do that.


Sure; in *that* case of course PUT is right...


in some cases, sling should be put in charge to create something "new
and unique" without the
developer having to choose... let's say adding new comments to a blog
post for example.


That's the case I was thinking of...


anyway, in hind-sight the /xyz/* for the POST is probably not ideal
and in my mind should
be deprecated in favour of /xyz/ with a trailing slash.


Yep. That would align it with how adding to collections works in AtomPub.

BR, Julian

Re: sling examples: sling-generated path

[Bertrand Delacretaz]

On Thu, Oct 16, 2008 at 5:14 PM, David Nuescheler <[EMAIL PROTECTED]> wrote:
> ...anyway, in hind-sight the /xyz/* for the POST is probably not ideal
> and in my mind should
> be deprecated in favour of /xyz/ with a trailing slash

The problem with not using xyz/* is differentiating between create and
modify operations.

If a POST to xyz/ always creates a new node under it, how to you
update a property on xyz itself?

Being able to use PUT would be the answer, but browsers don't do that.
We could have used HTTP headers to make a POST behave like a PUT, but
I think the magic star is easier to use from browsers, and more
visible than a HTTP header.

So my answer is: we currently use xyz/* as a workaround, to
differentiate between "create" and "modify" when working with today's
browsers as clients.

-Bertrand

Re: sling examples: sling-generated path

[David Nuescheler]

> Out of curiosity: why not just POST to the location? That seems to be more
> in sync with how POST is defined in HTTP...
for known resources this is the case... and everybody is welcome to do that.

in some cases, sling should be put in charge to create something "new
and unique" without the
developer having to choose... let's say adding new comments to a blog
post for example.

anyway, in hind-sight the /xyz/* for the POST is probably not ideal
and in my mind should
be deprecated in favour of /xyz/ with a trailing slash.

regards,
david

sling examples: sling-generated path

[Julian Reschke]

Hi,

I was just looking at the sling-in-15min tutorial, and came across the 
section "Let Sling generate the path of a newly created node", which 
describes using POST and "*" as last path segment...


Out of curiosity: why not just POST to the location? That seems to be 
more in sync with how POST is defined in HTTP...


BR, Julian