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 Fri, 24 Jun 2005 09:49:58 GMT
Mark Lundquist wrote:

>
> Hi Sylvain, thx for your reply...
>
>>  ....
>>
>>>         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.
>>>
>>>
>>> It's not a hard "name clash", but it is a nomenclature clash in that 
>>> it's a different sense of the term "model". My new row "model" 
>>> property is truly the "model", as in "MVC" or as in 
>>> "loadFormFromModel()". The v1 "model" is "model" in terms of 
>>> "formmodel", I guess. I just think it's too confusing to have both 
>>> senses. I actually sort of wish the v1 "model" were called something 
>>> else, because it isn't the model /a la/ MVC.
>>
>>
>> You're right. The "form.model" is actually the value tree.
>
>
> Maybe form.model should be renamed to "form.value"!  Then you would 
> have these two expressions that mean the same thing (just as they look 
> like they should! :-):
>
>     form.value.foobar
>
> and
>
>     form.lookupWidget('foobar').value
>
> , right? :-)


Yes, and also "form.value.foo.bar.baz" and 
"form.lookupWidget('foo/bar/baz').value". Naming it "form.values" 
(plural) sounds better.

> But for now in my working version of the code I settled on "rowModel" 
> to expose the row model object in Flowscript and JXT.
>
> Now then, the following exchange has me totally confused:
>
>>>>     It doesn't seem good to me to provide at the API level a way to
>>>>     link the form to the data model,
>>>
>>>
>>> No, no, it /is/ good... :-)
>>> [ ...my rambling snipped...]
>>>
>>>>     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.
>>>
>>>
>>> See, that's the problem, this is what I have to deal with currently 
>>> :-)... I have two parallel structures: a Collection, and a Repeater. 
>>> If the Repeater does not give me a "view" to its collection, then I 
>>> have to do some kind of iteration to create associations somewhere 
>>> between the repeater rows and the collection elements, and this just 
>>> feels silly and wasteful. I've done it this way, decorating the 
>>> repeater rows with handles to the model data, and I just think that 
>>> since the binding layer is already iterating across the collection, 
>>> it should do this decoration for me! :-).
>>
>>
>> Yes. That's the idea behind the "bound repeater binding" idea 
>> Reinhard pointed to.
>
>
> Right.  Which was your idea, and which I think I have gone and 
> implemented before I knew that somebody else had thought of it :-)...  
> Or have I not?  Maybe I am misunderstanding Reinhard's reference and 
> it isn't really the same thing... or maybe you are misunderstanding 
> me, and thinking it's not the same thing, but it really _is_? :-)
>
> Are you saying, "Ah yes, you're right... I thought of this before, and 
> now I remember why it _is_ a good idea (+1! :-)" ?
>
> Or — are you saying "Ah, it looks like I did think of this too once, 
> but now on second thought I'm not so sure it was a good idea" ?


LOL! I of course remember this was my idea, and I still think it is good.

What doesn't seem good however, is to provide a way to link the data 
model and the form, _without going through the binding_. It is ok for 
some bindings to use widgets attributes are storage areas for their 
stuff, but it isn't ok IMO for the _widget_ API to know about 
application data.

>>> I could live with there being a "callback" facility in the repeater 
>>> binding language, e.g. <fb:javascript> within <fb:on-bind>... know

>>> what I mean? But that's sort of beyond my ability to implement, and 
>>> I was looking for something that I could actually do :-)
>>
>>
>> Extending the repeater binding to keep the connection to the data 
>> model may be easier, no?
>
>
> Well, it certainly was awfully easy :-)  Tell you what, the change is 
> so ridiculously small, I'll just attach the diffs  (they are against 
> src/blocks/forms/java/org/apache/cocoon/forms) and you can see if 
> we're talking about the same thing.  At first this amounted to about 6 
> lines of code added, before I added the convenience flowscript 
> function (that I had mentioned in the original post that I wanted to 
> add... this doubled :-) the size of the mod).  BTW, this function — 
> 'getRowModel()' — I only added it in v2 ('cuz that's what I'm using! 
> :-).  When I looked at v1's ScriptableWidget, I hesitated when I saw 
> that there are so few javascript functions defined there, and I wasn't 
> sure if this is really the right idiom for v1... Care to comment?


Well, this is exactly what I consider as wrong above :-)

That's the binding job to possibly use widget attributes to store data 
that helps later on the form's save. But the form itself shouldn't have 
to care about it.

So the changes should be in RepeaterBinding, and not in Repeater itself.

Sylvain

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


Mime
View raw message