We found what it is. Quite logical actually. By default, optimizeItemRemoval is set to false, which means that ListView replaces all child components by new instances. The idea behind this, is that you allways render the fresh data, and as people usually use ListViews for displaying read-only lists (at least, that's what we think), this is good default behaviour.
However, as the component is replaced before the rendering starts, the search for specific messages for that component fails. It doesn't exist anymore! And there's more. The other problem is that 'wrong' user input is kept as (temporary) instance data of the components - the input fields in your case). And as these components are replaced by new one, your user will never see the wrong data. This may sound bad, but it is not too bad actually. The fix is to just set optimizeItemRemoval to true whenever your nest a ListView in a Form. There's only one disadvantage to that: when your list (the model of the ListView) changes, you have to manually notify ListView so it will render itself from scratch again. But that's probably something you won't need often in forms. Good luck, hope it solves your problem, and sorry it took us a while to look into your problem, Eelco ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
