This is one of the main reason that Igor made DataView.

On 9/14/05, Johan Compagner <[EMAIL PROTECTED]> wrote:
> 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
> > 
> 
>


-------------------------------------------------------
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