Also, this is a new problem for us. We have been working with frameworks like Struts, Maverick, Cocoon and even plain servlets/ jsp etc for years, and as with these you are used to take care that you can build up state from everything that comes in with the request, you never had issues like these. Now, imagine us displaying the new webapps we're working on... the very first thing one of our collegues did - just by accident - is pushing the back button somewhere where it shouldn't have been pushed (because he added an item to a list, and wanted to see the details of another item again)... Wham! Stale data page! So we start explaining them that this is our price of progress. Well, you understand this collegue did not really agree this was progress, especially because we never had this kind of things happening in other applications.
All, and I say ALL other frameworks deal with this issue. I don't know about Tapestry, but I understand that as it was a source of inspiration for Wicket, Tapestry does mark pages stale. I also understood that Tapestry manages state in a very different way, so I don't know whether it has the same issues as we have.
But JSF and .NET work alike in that they provide client saving state (which sometimes give our .NET devs pages of 1MB if they don't watch out). This is optional too, but if you use server side state, you run into problems with those frameworks as well. But they solve it if you want it. And Echo simply puts your webapp in frames and effectively disables the backbutton! So, this is definitively not to say that they do it better than we do, but I want to stress that the back button issue is an important issue.
If we're never going to clone/ copy/ create undo actions, I just can't see how we can solve this at all, except for removing replace and removeAll (yes I really think they are the same in what problems they represent) and thus forcing users to develop in a page based manner. This might be the ultimate solution, but it would also reduce the ability to write reusable components greatly.
I understand, and share, the gut feeling you have against any form of cloning in Wicket. Therefore, I think we should really agree all on this before we put it in any version at all. But, and I have made this an issue a couple of times before, SUPPORTING THE BACKBUTTON IS REALLY IMPORTANT.
What we came up with is probably not the perfect solution as it was our first cut at it (though we had offline discussions about it for months). But please take it as a starting point for working to a real solution instead of just postponing it.
Eelco
this is a fundamental problem with browsers and back buttons that isn't going away and wicket solves this problem. as i mentioned in an earlier email to someone else, we can do a better job of marking pages stale (right now we're marking more pages stale than need to be), but the pages really /are/ stale because the markup no longer matches the model that the markup wants to edit.
------------------------------------------------------- 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
