Jonathan Locke wrote:
i'm trying to mentally walk the line here between giving up on what johan wants and sharing the same worries you do. the only compromise i can see so far is this:
1. try to improve staleness detection, if possible. consider limiting staleness detection to forms with affected mutator components.
I really like to see youre implementation for this :))
2. restrict cloning to uses of replace() only, ensuring that only then is cloning ever done.
removeAll really has exactly the same affect.
3. put a warning on any component that uses replace() that the component will cause the page to be cloned and have a lengthy discussion in the same javadoc of what that will mean to the user
i agree. And i still say, feature is not enabled by default....
i've got to say that even though i'm looking for compromise (especially because that has been so productive on wicket to date!), my gut instinct is still that we should remove replace() and never clone anything. frankly cloning scares me anytime i see it.
Then how are tabpanels handled nicely.. Especially the nested onces (we send you a picture)
Almost all our webapps work that way. Everythings is tabs in tabs in tabs.
I agree that the highest tab is not a problem. The problem arises in nested tabs.
setVisible i really don't like because then we get one big HUGE (and i mean really HUGE) page.
johan
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
