cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: [CForms binding] access to model data from repeater row widget
Date Tue, 21 Jun 2005 06:42:23 GMT
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.

> It seems like each time, I come up with some different way of handling 
> this, and none of them ever feels quite right.
>
> Then I thought, if the binding framework would decorate each repeater 
> row widget with a property that references the bound object, things 
> would just be a lot cleaner.
>
> So I made this trivial change, and it works great. The repeater rows 
> now have a "model" property that references the model object to which 
> that row is bound. I tweaked the JXTG macro version of the template 
> engine so that I can reference "${model_}" from within the 
> <ft:repeater-widget>. That is really handy, because it lets me avoid 
> having to specify a bunch of output widgets in the the form definition 
> + binding. What I really had in mind with this change, though, was 
> making the flowscript easier, and it does do that... but currently in 
> the flow I have to unwrap() the repeater row widget by hand before I 
> can call getModel() on it, so before I finalize this I want to add 
> that to the Form flow API. Then I think it will be just right.
>
> However...
>
> I realized that I have a nomenclature clash with my choice of the name 
> "model". I've been using the v2 API for a long time, so I forgot in 
> v1, there is a Form.model property that denotes the widget value tree.


The "model" property is only available on the toplevel form JS object, 
so there may not be a clash. BTW, why do you prefer v2 rather than v1?

> So I don't want to cause confusion with another sense of "model"... it 
> should be called something else. "rowData"? "rowObject"? WDYT?


It doesn't seem good to me to provide at the API level a way to link the 
form to the data model, as this is something that isn't suitable for all 
situations (think transactional systems, heavyweight objects, etc). And 
one of the big strengths of CForms is its strong isolation with the data 
model while the user is messing around with input values.

However, there are some uses cases where this makes sense. You can then 
use widget attributes (see get/setAttribute) to attach some application 
data of your liking to any widget, including repeater rows.

You can also have a look at the new Tree widget in trunk. It relies on a 
lightweight model to access arbitrarily large hierarchies. And a 
repeater is not far from being a tree of depth 1 :-)

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://apache.org/~sylvain            http://anyware-tech.com
Apache Software Foundation Member     Research & Technology Director


Mime
View raw message