I have said this now quite a few times
Model changes/staleness is the developer responsibilty
There is now way wicket can fix this. Besides the current branched one where we just make a copy of everything.
Look i will make an example what i mean with the developer that is responsibel with listview.removeall.
I have a list with object (Users or what every)
I know as developer that i can have stale pages for this view so what do i do as developer when i make a listitem?
I hold the direct reference to that User object OR an id so that i can reaquire that User object...
populateItem(ListItem item)
{
final User user = item.getModelObject();
item.add(new TextField("name",user,"name");
item.add(new Link("delete")
{
onLinkClicked()
{
xxx.removeUser(user);
listview.removeAll();
}
}
}and this i have 10 times in my ListView
In removeAll i do my Undable thing.
So the next time the back button is used. The call to the above removeAll is reversed (so only above link is also there again)
Then ofcourse if it pressed exactly that link i have some handling to do because it removes a user twice. But that is up to me as developer.
But all other links just work! If they are doing something with another listitem (its brother) then the ListItem has all the state he wants
without going to the model.
So I as developer will only use the model data that i know will change only in the render/creation of components phase.
After that i will not use the model anmore. Because it can be changed anyway. For example another user in another
session could also have removed a user. So in my few models are after rendering ALL stale (at least the onces with shared
data, so pretty much everything that comes from a database)
This Only knows the developer. Wicket can never see this.
You exactly are giving my my point in saying that models can be anything. Yes they are exactly!
Thats what i thing wicket can never get a 100% solution because of those models.
At component level thats an other league.
I wasn't upset. You will never get me upset. That is not my nature... :)
Thats why we where branching. And i have to say that because of that we now have a big discussion
So yes i am and will always be. First try to implement something so that you can see what really happens
instead of talking and talking and talking about it.
I will try to make another branch this weekend where i will work out the Undable support
First only for components. But if you guys are comming up with a great idea how this can also be handled for models
then this would be great!!
johan
Jonathan Locke wrote:
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
------------------------------------------------------- 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
