cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: [cforms] Radio buttons across repeater
Date Wed, 07 Apr 2004 22:03:14 GMT
On 07.04.2004 14:08, Marc Portier wrote:

>>> with it you wouldn't even need to declare it in your form-definition 
>>> since it really only has a purpose for the binding, and actually 
>>> never really is a true/valid widget, or is it?
>> Not necessarily. I have two cases. One overview list of persons where 
>> an action
>> leads to a detail view. Here I need the ID in the flow/form model. And 
>> another
>> list view (the addresses, as part of person's detail view) where I do 
>> not need
>> to link, the addresses are completely edited in the list view. For the 
>> latter I
>> wanted to remove @unique-row-id/@unique-row-path, but that's not 
>> optional. So I
>> need a widget which is bound to the ID.
> got it, but there is nothing that prevents it:
> I don't think the row-idenity approach prevents you from declaring an 
> aditional id-widget in your definition file when you do need it.

Of course. It was only to show that there are some case where it is a 
widget in contrary to your sentence above.

> the image as it is starting to clear out in my head:
> - repeater has now alreday a list of rows
> - it could also maintain a hashmap where those rows with identity would 
> be hooked up (identity is set programmatically e.g. under control of the 
> binding)
> - rows added by front-end interaction would be identity-less and stacked 
> up in a set of unIdentifiedRows under the repeater
> all of this doesn't mean that there could not be one of the widgets 
> inside the row holding an 'id' value (even user updateable)
> making sense?


> -marc=
> PS: this would completely set asside the IdentityBinding interface we 
> discussed earlier, I do hope you are glad you didn't spend your valuable 
> time on that :-)

Thanks again ;-)


View raw message