> well for the moment I'm quite happy with setOptimizedItemRemoval, but > I think this will not last very long because removing all components > isn't the thing to do when a model update occurs.
A model update should not be a problem. As long as your model is not static, your page should be updated with each request. >When I need this > functionality I will see what I can do. Getting this "done right" > seems to be a bit tricky... I think the right solution would involve > not working with collection indexes for matching model object and > ListItem. One solution could be building an internal map of model objects and > ListItems (so it doesn't get out of order when removing or adding > items from the model list). Not sure what you mean. a) A map does not provide a sequence b) a ListItem does already have a relationship to a model. How does your approach differ from the current one? >The populateItem method could be called > with the ListItem which maybe was generated already, so the > populateItem method can decide if it wants to generate (first time) > or regenerate or refresh the components. > I'm not sure if this is the right way and if this should be > implemented as patch to ListView or as separate component... What do > you think? I must admit I don't understand what is different to the current approach. IMO we need a simple flag which prevents calling populateItem on each request, rather than only on the first one (assuming the list does not change). Juergen ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
