yeah, but i think that's only part of the solution too...
i've been thinking more about removing the whole concept of renderCount and staleness and adding a concept of "version" to Pages. that's really the correct concept.
in this world, the framework could add the version to the URL in the same way it currently adds renderCount, but the version would only change when the Page actually was changed.
once you start thinking about this in general, it leads to a pretty nice abstraction, where you might have things like Page.this.getVersion(int version) and some version manager that plugs into this which can give you an alternate version of a Page in the same way that PageState can produce a page on demand. version managers could be implemented any way we want to implement them, whether cloning the whole page or undo or somet other method we haven't yet thought of.
so i think the way that a version of a page is produced should be entirely up to the programmer if they're willing to do some work. and then just one of the tools that they can use is this undo concept which would simply be a delegate that implements Page.this.getVersion(int version) not quite in the form you suggest. an undo delegate would attempt to mutate a page back to a given version. a custom delegate might wind up acting like a page factory, creating the given version.
so perhaps the way it works is this... the name of a Page /optionally/ becomes "<id>:<version>" (only as soon as the page becomes versioned). then request URLs are stamped with a version number as well (and not as a query parameter) so that when a request comes in, wicket looks for a page named "<id>.<version>" first (since that may have been produced by a factory-style implementation of getVersion()). if it cannot find that, then it looks for "<id>" and if the page it finds with that id is not of the right version, then it asks the Page it does have to produce a Page of the right version. if the page cannot produce a page of the right version, then the URL is stale and some handler method is called like onStale() to allow the programmer to deal with the problem.
this is all just what i can think up on the spot though and i'd like a chance to work the problem and talk with chris tomorrow morning....
best,
jon
Gili wrote:
On Mon, 07 Mar 2005 22:19:52 +0100, Johan Compagner wrote:
You never be able to do a undo of the model data without getting some data somewhere
We as wicket (the framework) don't know nothing about the models and there data. So without cloning/copying
we can't do anything i believe.
I thought we agreed that there should be two levels of undo: one where Wicket undoes its own model states automatically and another where the user registers his own UndoableEdits to undo the user-data. Wouldn't that work?
Gili
------------------------------------------------------- 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
