on the right /kind/ of list changes, the back button doesn't work in any case! this is not wicket's fault. the problem is the whole design of web browsers.
think back to my example of a list of textfields. if you delete the row with only one textfield in it by changing the listview model, then hitting the back button /must/ result in a stale page.
i think what your frustration is right now just has nothing to do with this cloning issue... the issue is that we're overzealous in making pages stale. this is a constraint we could lift somewhat in 1.1 once we figure out how to do it. the modelStructureChanged() method should be called religiously when the model object is altered in a way that changes the sturcture of the view. there is simply no other way to know if there was a change, short of wrapping every list in a mutation detection wrapper (which seems a little overzealous). what we do right now is removeAll(). but in the future, we could make our components smarter by determining if mutator components are involved in the model which changed structure. it's only THEN that the back button really cannot work (IN ANY FRAMEWORK). make sense?
No
I am and will always be completely against the current modelStructureChanged() call. I will not call that method in any web app i make.
complete pages itself shouldn't be stale and then i mean the pages with List of records.
Let's take an example
I have a pages with a list of users. That can be editten or deleted.
So you are saying when I (the user itself) deletes a user the page should be stale...
Then i say.. Why? Why then?
Why not immediantly after rendering the page the first time?? Because another user can also show that same page (in his session) and delete a user at the moment
i am viewing that user in my list.....
So declaring it only stale when I remove is ridiculus and the error the developer should catch is he still haves to do because the user can be deleted anyhow...
Thats why i am agianst stale pages. What is stale is the link of that specific deleted user. (the edit or remove link)
ALL other links on that pages are NOT stale.
For example this just have to work:
List users (10 are listed)
delete user3 and i see the next page of 9 users
but i press the back button.
See 10 users (the first page, with user3)
now if i delete user4 wicket shouldn't throw any error. User4 should just be deleted and the next page of now 8 users should be displayed
If i click again back. And see that 10 list again.
And i delete user3 or user4. THEN a stale error should be thrown.
This is a developer responsibility. Because this is something he as to take into account that a user can be deleted. He can choose to silent ignore it
(for example if the delete link is clicked on a deleted user). If a edit is clicked on a deleted user he could return to the list with a feedback message.
But no, no way i want a stale page that i suddenly have to go to the home page and go completey back to the pages i was!!! This is unacceptable.
In the above example you would call modelStructureChanged() now my next example where would you call modelStructureChanged??
2 web app users both are listing the users both see 10 users. then webappuser1 deletes user5 then a few ms after that webappuser2 says: delete or edit user5. what then?
The model is changed... but in another session... that also affect that one in the componentListener call phase.....
hmmm
Error!
So the developer have to take this into account anyway so i prefer myway to not make anything stale.
And let the developer handle the stale links in a page. I as developer want this control because i have to do it anyway.....
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
