Johan Compagner wrote:
Yes and that is the problem
I don't care about model changes at the moment, Models can change everywhere, anytime,anyplace.
The thing that is the big problem is that the componentstrucure is not the same anymore with the view on screen (because of a back button)
this happens in 2 places:
1> replace (tabpanels) 2> removeAll (listview)
That is the problem we are trying to fix. So please keep it purely focused on that.
i'm sorry, johan, but i really don't agree. at least for myself, i am no longer just trying to solve the tab panel problem. we've opened the scope up a level and we're re-analyzing the back button problem and i think we need to state the problem precisely instead of just throwing stuff at the wall to see what sticks. the whole reason removeAll() and add() are being called in listview is because the model changed. this matters. it also matters that in a listview the model for a listitem is the list and an index and not an object model. it matters that we haven't rigorously defined and scoped our problem. we're going to have to really think about this stuff if we want a decent solution. throwing up our hands and providing a few ad hoc tools that might help just isn't enough.
the fact that you're using hibernate and are going to have hibernate do change detection for you and you think that will take care of all other problems for you is really outside the scope of wicket. in the end, wicket has to deal with model objects in the abstract as well as it can and not expect lots of work and some magical attribute of how model objects are managed to just take care of everything. now, it may turn out that you're right that wicket can't do much more than its doing, but i'd like you to humor me for a couple of days. just yesterday, you were upset because i didn't want to plunge ahead and merge changes into HEAD to add cloning-via-serialization to wicket. today, we no longer want to do that. i suspect that our current guess-at-a-solution isn't the final thing either. anyway, if you don't really want to help re-analyze the back button problem, please at least let those of us who are trying to re-examine it proceed. given the new perspective we have, i really think it's worth doing. and frankly, if NOBODY wants to think about the problem, i'll just go do it on my own. it's not like i'm getting paid for this.
so would anyone like to respond to my post last night about listview models and indexes or my stab at defining the problem?
i think martijn is dead-on right. with something this complex, it would really behoove us to step back and really define the whole problem and not just try to solve little bits of it based on our intuition or present special need.
------------------------------------------------------- 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
