[POST servlet] Patching multi-value properties

[Alexander Klimetschek <ak...@adobe.com>]

Hi all,

I'd like to propose an extension to the Sling POST servlet.

Use case:

Often you have multi-value properties that act as sets, i.e. they only
contain at max one value and are not a list. An example would be tags. In
this case, having to rewrite the entire array in the POST is not optimal,
sometimes you just want to say "add valueX" or "remove valueX". Our
specific use case is bulk-editing of multiple resources, where you want to
say "add or remove valueX to/from the set", regardless of whether the
certain mv property has the value or not. That should be automatically
done by the POST servlet.

Solution:

Add a new "@Patch" suffix:

my:property@TypeHint=String[]
my:property@Patch=true
my:property=+value1
my:property=-value1

When "@Patch=true" is present, each of the property values from the
request are expected to start with either "+" or "-", followed by the
actual value. These two would represent the operations you want to have
executed on the set.

WDYT? I would provide a Patch-patch ;-).

Regards,
Alex

-- 
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel

Re: [POST servlet] Patching multi-value properties

[Alexander Klimetschek <ak...@adobe.com>]

On 27.01.11 15:59, "Alexander Klimetschek" <ak...@adobe.com> wrote:
>The "add" operation would be implemented as (pseudo code):
>
>Values[] v = prop.getValues();
>if (v contains "value1") {
>    v += "value1";
>)

Ah, this should of course be

if (not (v contains "value1")) {
    v += "value1";
)


Also, if we want to support lists as opposed to sets, the operations are
different and would be at least:

- insert val, pos
- remove pos

And could be arbitrarily extended to:
- append val
- prepend val
- remove val
- removeAll val
etc.

and I think in the list case it is better if the client gets the whole
list, edits it and sends it back. The main point of the set operations is
that the client does not need to know how the full set looks like, which
is what is the case in the bulk-editing scenario.

Regards,
Alex

-- 
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel

Re: [POST servlet] Patching multi-value properties

[Alexander Klimetschek <ak...@adobe.com>]

On 27.01.11 15:25, "Bertrand Delacretaz" <bd...@apache.org> wrote:
>>my:property@TypeHint=String[]
>> my:property@Patch=true
>> my:property=+value1
>> my:property=-value1
>
>I like the idea but a (slight) problem is that this is not idempotent,
>if the client repeats the request value1 will be added twice.

No, as I mentioned, this is under the assumption of the mv property being
a set.

The "add" operation would be implemented as (pseudo code):

Values[] v = prop.getValues();
if (v contains "value1") {
    v += "value1";
)

And the "remove" operation would be:

Values[] v = prop.getValues();
for each (Value val in v) {
    if (val == "value2") {
        v.remove(val);
    }
)


Regards,
Alex

-- 
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel

Re: [POST servlet] Patching multi-value properties

[Bertrand Delacretaz <bd...@apache.org>]

Hi,

On Thu, Jan 27, 2011 at 3:11 PM, Alexander Klimetschek
<ak...@adobe.com> wrote:
>... Add a new "@Patch" suffix:
>
> my:property@TypeHint=String[]
> my:property@Patch=true
> my:property=+value1
> my:property=-value1

I like the idea but a (slight) problem is that this is not idempotent,
if the client repeats the request value1 will be added twice.

To make it (optionally) safer you could have two values for @Patch,
"fast" (non-idempotent) and "safe" which only adds value that do not
exist yet.

-Bertrand

Re: [POST servlet] Patching multi-value properties

[Vidar Ramdal <vi...@idium.no>]

On Mon, Jan 31, 2011 at 2:19 PM, Alexander Klimetschek
<ak...@adobe.com> wrote:
> Hi again,
>
> could I assume silent agreement to this feature? ;-)

No. I agree loudly :)


-- 
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00
Quando omni flunkus moritatus!

Re: [POST servlet] Patching multi-value properties

[Alexander Klimetschek <ak...@adobe.com>]

On 01.02.11 04:10, "Justin Edelson" <ju...@gmail.com> wrote:
>On Jan 31, 2011, at 12:27 PM, Alexander Klimetschek <ak...@adobe.com>
>wrote:
>
>> The latter is not really possible... one must be able to remove certain
>> parameters from the request or from the RequestProperty list to do so.
>> Maybe the collecting of the RequestProperty map is done before the
>> PreProcessors are called and they can modify the map?
>
>Definitely. I wonder if this could obviate the need for PostOperation
>composition.

You mean https://issues.apache.org/jira/browse/SLING-1725 ? I think this
still has its use case, as sometimes you want to call a PostOperation
directly from your code, without having to do an HTTP request or internal
request dispatcher. And "your code" would be more complex or triggered in
a very different way, than that it could be replaced by a PreProcessor.

Regards,
Alex

-- 
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel

Re: [POST servlet] Patching multi-value properties

[Justin Edelson <ju...@gmail.com>]

On Jan 31, 2011, at 12:27 PM, Alexander Klimetschek <ak...@adobe.com> wrote:

> The latter is not really possible... one must be able to remove certain
> parameters from the request or from the RequestProperty list to do so.
> Maybe the collecting of the RequestProperty map is done before the
> PreProcessors are called and they can modify the map?

Definitely. I wonder if this could obviate the need for PostOperation composition.

Justin

Re: [POST servlet] Patching multi-value properties

[Alexander Klimetschek <ak...@adobe.com>]

On 31.01.11 18:13, "Julian Sedding" <js...@gmail.com> wrote:

>What about taking up the discussion about a PreProcessor interface as
>a hook into the post servlet? This was considered and discarded in
>SLING-594. This seems to be a use-case, which could be solved using a
>PreProcessor (essentially, this would allow the @Patch feature to be
>implemented outside of Sling).

The question is how this would look like: the PreProcessor must be able to
work on the jcr session and fill the list of changes (possible with the
proposed PreProcessor interface, see below) but also to stop the standard
operation to use certain request parameters.

The latter is not really possible... one must be able to remove certain
parameters from the request or from the RequestProperty list to do so.
Maybe the collecting of the RequestProperty map is done before the
PreProcessors are called and they can modify the map?

interface PreProcessor {
    void process(SlingHttpServletRequest, List<Change>);
}


Regards,
Alex

-- 
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel

Re: [POST servlet] Patching multi-value properties

[Julian Sedding <js...@gmail.com>]

What about taking up the discussion about a PreProcessor interface as
a hook into the post servlet? This was considered and discarded in
SLING-594. This seems to be a use-case, which could be solved using a
PreProcessor (essentially, this would allow the @Patch feature to be
implemented outside of Sling).

Regards
Julian




On Mon, Jan 31, 2011 at 5:48 PM, Alexander Klimetschek
<ak...@adobe.com> wrote:
> On 31.01.11 14:57, "Felix Meschberger" <fm...@adobe.com> wrote:
>>Point is, as Bertrand pointed out, the proposal results in fragile
>>behavior.
>>
>>In addition the values of a multi-value property is not a set of value
>>but an array of values, which means there can be duplicates and the
>>values are ordered.
>>Thus, while agreeing with the fact, that it looks like making
>>applications simpler to only be required to supply a +/- list, it is
>>probably not that easy...
>>
>>To make it stable (or more stable if you wish), we would need the
>>following operations:
>
> That depends on the use case. The @Patch "mode" is meant for the "set" use
> case and covers all existing operations for that (add and remove). If you
> have the list use case, updating the entire array (as you would do
> normally now and without @Patch) is more convenient anyway than the
> complex set of list operations.
>
> We could change @Patch=true to maybe "@Mode=patch" or "@Mode=set" to be
> able to add a "@Mode=list" later. But honestly I don't see the benefit of
> single list operations over sending the entire array... since the client
> must know the entire list anyway to properly define the list operations.
>
> Note that in the "set" case, the client is _not_ required to know the set
> at all!
>
> Regards,
> Alex
>
>
> --
> Alexander Klimetschek
> Developer // Adobe (Day) // Berlin - Basel
>
>
>
>
>

Re: [POST servlet] Patching multi-value properties

[Alexander Klimetschek <ak...@adobe.com>]

On 31.01.11 14:57, "Felix Meschberger" <fm...@adobe.com> wrote:
>Point is, as Bertrand pointed out, the proposal results in fragile
>behavior.
>
>In addition the values of a multi-value property is not a set of value
>but an array of values, which means there can be duplicates and the
>values are ordered.
>Thus, while agreeing with the fact, that it looks like making
>applications simpler to only be required to supply a +/- list, it is
>probably not that easy...
>
>To make it stable (or more stable if you wish), we would need the
>following operations:

That depends on the use case. The @Patch "mode" is meant for the "set" use
case and covers all existing operations for that (add and remove). If you
have the list use case, updating the entire array (as you would do
normally now and without @Patch) is more convenient anyway than the
complex set of list operations.

We could change @Patch=true to maybe "@Mode=patch" or "@Mode=set" to be
able to add a "@Mode=list" later. But honestly I don't see the benefit of
single list operations over sending the entire array... since the client
must know the entire list anyway to properly define the list operations.

Note that in the "set" case, the client is _not_ required to know the set
at all!

Regards,
Alex


-- 
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel

Re: [POST servlet] Patching multi-value properties

[Felix Meschberger <fm...@adobe.com>]

Hi,

Am Montag, den 31.01.2011, 13:19 +0000 schrieb Alexander Klimetschek: 
> Hi again,
> 
> could I assume silent agreement to this feature? ;-)

Sorry, to not have spoken up till now -- consider this silent
disagreement ;-)

Point is, as Bertrand pointed out, the proposal results in fragile
behavior.

In addition the values of a multi-value property is not a set of value
but an array of values, which means there can be duplicates and the
values are ordered.


Thus, while agreeing with the fact, that it looks like making
applications simpler to only be required to supply a +/- list, it is
probably not that easy...

To make it stable (or more stable if you wish), we would need the
following operations:

   prop[idx]=value -- set(idx, value); replace value at position idx
   prop[idx]-      -- remove(idx); remove value at position idx
                      (moving all elements at idx+1..len-1)
   prop[idx]+value -- insert(idx, value); insert value at position idx
                      (moving all elements at idx..len-1)
   prop+value      -- append(value); append value to the end

It is still not idem-potent, but neither is a POST request
to /some/location/ which generates a new node on each request. But it is
more stable and easier to implement.

WDYT ?

Regards
Felix

Re: [POST servlet] Patching multi-value properties

[Alexander Klimetschek <ak...@adobe.com>]

Hi again,

could I assume silent agreement to this feature? ;-)

Regards,
Alex

-- 
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel

Re: [POST servlet] Patching multi-value properties

[Alexander Klimetschek <ak...@adobe.com>]

On 27.01.11 15:11, "Alexander Klimetschek" <ak...@adobe.com> wrote:
>I'd like to propose an extension to the Sling POST servlet.

I created http://issues.apache.org/jira/browse/SLING-1983 for this, and
attached a patch, which - as a side-effect -  simplifies the rather
complex set property logic in the post servlet code.

Let me know what you think (in the jira).

Regards,
Alex

-- 
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel