cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: [cforms] Radio buttons across repeater
Date Wed, 07 Apr 2004 12:08:35 GMT


Joerg Heinicke wrote:

> Marc Portier <mpo <at> outerthought.org> writes:
> 
> 
>>>>In light of the above we could even consider sending 
>>>>repeaterID.radioID=row-identity (which would require to 
>>>>serialize-to-string somehow this identity?)
> 
> 
> <snip what="separate backend IDs from frontend IDs"/>
> 
>>+1
>>
>>I'm still running around the hot soup of repeater-binding (in my head)
>>and your scenario (which I think is quite widespread) of the wd:output 
>>that never gets styled is for me an additional reason for having an 
>>intrinsic Identity property on each Reater.Row
>>
>>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.

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 :-)
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                http://blogs.cocoondev.org/mpo/
mpo@outerthought.org                              mpo@apache.org

Mime
View raw message