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
