Hi,
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).
well, as long as the list doesn't change everything is fine, indeed.
But actually list changes can occur, for example after editing/
deleting/inserting entries. There should be a way to express how
these changes should be handled. Lets see what can happen:
1) List item added -> Generate the components
2) List item removed -> Throw away components
3) List item has changed -> Throw away component and re-generate them
OR notify components of model changes
The application should be able to decide how these changes are to be
handled, especially for case 3.
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 current default ListItemModel class uses the list indexes to get
the ListItem from the model list item. When keeping the components
using setOptimizedItemRemoval and an item is inserted before other
entries, chaos occurs. This will not work for a component which
allows model upgrades without throwing away the existing components.
Regards,
Ralf
-------------------------------------------------------
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_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
