You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Bruyn Bill <Br...@mcao.maricopa.gov> on 2006/04/11 19:48:49 UTC
FW: [CForms binding] access to model data from repeater row widget
This is probably a question more suitable for the dev-list...
-----Original Message-----
From: Bruyn Bill
Sent: Monday, April 10, 2006 3:18 PM
To: 'users@cocoon.apache.org'
Subject: [CForms binding] access to model data from repeater row widget
Taken from: http://www.planetcocoon.com/node/2423#comment
>Re: [CForms binding] access to model data from repeater row widg
>Sylvain Wallez - June 21, 2005 - 06:50
>>Mark Lundquist wrote:
>>Hi,
>>
>>Here is a scenario that I keep finding myself dealing with...
>>
>>Some repeater is bound to a collection, and also contains one or more
>>widgets that are /not/ bound to the collection elements. For instance,
>>there might be a checkbox that means "do something to/with the thing
>>in this row". After accepting the form, the processing entails
>>iterating through the rows and doing something something with the
>>corresponding object from the model layer, which means I need to be
>>able to find/access that object.
>
>
>So in essence, you want to act on the selected rows, right? I
>encountered this already, and I've been thinking to explicitely add the
>selection concept to repeaters. That selection would be defined by a
>boolean field present on each row. Note that a boolean field doesn't
>necessarily means rendering as a checkbox. It can also be some
>highlighting of selected rows.
>
>That would lead to
><fd:repeater name="repeater" selection="select">
> <fd:widgets>
> <fd:field id="name"/>
> <fd:booleanfield id="select"/>
> </fd:widgets>
></fd:repeater>
>
>Repeater actions such as "delete-rows" would then no more have a need
>to
>be given the select widget's name as of today.
>
>And even more, repeater actions could have constraints on the selection
>size, such as single-selection, multiple-selection, leading these
>actions to be disabled if their associated constraint isn't met.
>
>And finally, we may be able to specify on repeater bindings if they
>have
>to act on the whole repeater on just on the selection.
Has this gotten any traction? Is it still reasonable?
Thanks,
Bill