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?
Absolutely.
-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 ;-)
Joerg
