+0

I think this use case (for me) would be just over the line: the correct answer 
would be to write a custom servlet (as you did).  Making the sling POST servlet 
more complicated doesn't seem worth it.

But I don't feel strongly (thus the +0).

Jeff.


> -----Original Message-----
> From: Alexander Klimetschek [mailto:[email protected]]
> Sent: 15 August 2012 18:30
> To: [email protected]
> Subject: [POST servlet] Wildcard for deleting properties
> 
> Hi,
> 
> I had an interesting use case, which could be solved by allowing something
> like this in the Sling POST servlet:
> 
> *@Delete = true
> 
> Which would delete all properties and child nodes of a node, without the
> client knowing which are there. Similarly, this could also apply to @CopyFrom
> and @MoveFrom.
> 
> WDYT?
> 
> Here is my use case: I want to basically rewrite a node's sub tree (including
> its properties), while *not* recreating the node.
> 
> The latter is important because it's an ordered child node. Once I recreate
> the node in some way (explicitly or using @CopyFrom or @MoveFrom), I am forced
> to do 2 additional requests - one to get the initial order and remember it,
> and then a separate one to do the ordering, as the :order operation only works
> with the request resource, so you can't hook it into a post call which does
> other things first. And since I really want an atomic operation (one request
> and one session.save()), this approach is not feasible.
> 
> With a *@Delete approach I (think I) could do my rewriting (in my case moving
> the node's sub tree down to a sub node; using two @MoveFrom calls and a
> temporary node) in one step.
> 
> Note that I looked at all approaches I could find. This includes a json
> roundtrip using :content-import, but this also doesn't support rewriting a
> node's properties without replacing the entire node itself, and it would force
> another reorder call if I rewrite things. (Note that I really do *not* want to
> touch the siblings of the node, i.e. doing a larger rewrite). Currently I have
> a custom servlet doing the necessary steps.
> 
> Note that I already wrote a special servlet to handle my case, so this might
> not be too important. Just in case others see the same need.
> 
> Cheers,
> Alex

Reply via email to