Hi,
Actually, this functionality is AFAIU already present - see
ModifyOperation.collectContent - where a parameter name may in fact be
an absolute or relative path to a property to be set.
So infact, the Accept radio button could in fact be coded as:
<input type="radio" name="foo/bar/state"
value="accepted">Accept</input>
I think this is more intuitive that to try do a dot to slash mapping.
WDYT ?
Regards
Felix
Am Donnerstag, den 15.05.2008, 14:16 +0200 schrieb Bertrand Delacretaz:
> Hi,
>
> For SLING-458, I think it might be useful to accept path names as part
> of the parameter names.
>
> Here's an example use case, "moderation of blog comments", as a justification.
>
> A form displays a number of blog comments on a single page.
>
> Each comment has a radio button group with 3 values: accepted, rejected, spam.
>
> A single POST stores all the data, with no custom server-side or
> client-side code.
>
> My suggestion in such a case is to encode the path of each Property to
> modify in the corresponding radio button names, i.e.
>
> <input type="radio" name="property.foo.bar.state"
> value="accepted">Accept</input>
> <input type="radio" name="property.foo.bar.state"
> value="rejected">Reject</input>
> <input type="radio" name="property.foo.bar.state" value="spam">Spam</input>
> <input type="radio" name="property.foo.baz.state"
> value="accepted">Accept</input>
> ...
>
> Where foo.bar.state maps to the foo/bar/state path of the Property
> that is to be modified (and property..foo.bar.state maps to the
> absolute /foo/bar/state path).
>
> This could be added later to the SlingPostServlet, probably using a
> specific :operation parameter value to activate this behaviour: we
> don't want any field named "property.*" to be processed like this, but
> in cases like the above one I think it's very convenient.
>
> WDYT?
>
> -Bertrand
