Re: [CForms binding] access to model data from repeater row widget

[Reinhard Poetz <re...@apache.org>]

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.
> 
> 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. So I 
> don't want to cause confusion with another sense of "model"... it should 
> be called something else. "rowData"? "rowObject"? WDYT?
> 
> please advise! :-)

no advice but a link: see 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109950611823830&w=2


-- 
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------