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 <[email protected]> wrote: > On 31.01.11 14:57, "Felix Meschberger" <[email protected]> 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 > > > > >
