Updating by index works fine as long as the List behind it never changes.

So if you know 100% sure that over request the list will not change (add/remove/order)
then you can use index just fine.
But if you have a list of 10. and Index 1 points to a user "Jim" at render time.
Then User "Johan" is inserted at index 1 and user "Jim" is gone to index2.

If now a update model comes in then the a textfield holding the name "Jim" will be bound to a
ListModel with index 1. He will get the user at index 1 but that is suddenly "Johan"
And you will override everything of Johan with Jim. So suddenly you have 2 jims...
(Maybe in this example that would be better, having no Johan but 2 jims ;))

If you store the ID of the user instead of the Index then before you update the model
the user is loaded with its id. So it will not go wrong.

So the rule is pretty simple:
Can the list change over/between request yes or no. If yes then store id's
if no then you can use index.



On 9/13/05, Jim McBeath <[EMAIL PROTECTED]> wrote:
On Tue, Sep 13, 2005 at 09:07:56PM +0200, Eelco Hillenius wrote:
> I think that is how ListItem started out many months ago. There have
> been several been several shouting indecent words about that, and it
> was 'fixed' to what it is now. I don't know, someone else (Johan?)
> should defend that decission.

I would be interested in hearing about the potential problems associated
with updating the underlying List using the index.  If this has all been
discussed before, I expect I could learn something from that discussion.
I would not want to implement my own fix to do this, then run into some
subtle problem down the road that has already been discussed here.
Can anyone point me to an old discussion about this, or post a summary?

If ListItemModel will not update the underlying list, should it perhaps
not allow it's value to be set?  I'm curious to see an example of where
the ability to set the local object in the ListItemModel is useful.
If others, like me, assume that the ListItemModel is usable for updating
the underlying List, it would be helpful to have ListItemModel.onSetObject
throw an exception with a message telling the developer that he can't do that
and will need to come up with another approach.

--
Jim


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user

Reply via email to