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/
[EMAIL PROTECTED] [EMAIL PROTECTED]

Reply via email to