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