basically pagemaps are gone. this was made possible by changing how
page versioning works and has resulted in much simpler code to both
committers and clients.
in 1.4.x a page has both id and version. id is assigned on page
creation and version is incremented every time the page is tweaked.
page history is kept as a series of undo objects. problems: undo
objects are cumbersome to create and maintain. since IChange only has
undo and not redo once we roll back a version there is no way to go
back.
lets take a look at how this effected simple things such as multi tab browsing:
user loads page id 5 version 3 in browser tab 1.
right clicks a link and clicks open in new tab.
without multi tab support enabled
link handler executes, creates version 4
page id 5 version 4 opens in a new tab
user switches to old tab and clicks a link
page is reverted to version 3 because that is the version of the
link in the old tab
version 4 that is open in tab 2 is evicted by the undo operation
new version 4 is created for the page in tab 1
user switches to tab 2, clicks, gets component not present or weird effect
with multi tab support enabled
link handler executes, creates version 4
wicket detects page id 5 version 4 is opened in a new tab
wicket clones page into new pagemap
user interacts with new page in the new pagemap, page open in tab
1 is not affected.
in 1.5.x there is no version, there is just the page id. whenever a
user creates a change in a page that previously required a new version
in 1.5.x we clone the entire page into one with a new page id.
effectively creating a DAG of versions of a page as it is being
modified.
lets take a look at how this eliminates the need for complex code like
multi tab support:
user loads page id 5 in browser tab 1.
right clicks a link and clicks open in new tab.
link handler is invoked, modifies the page, page id is changed to 6
page 6 renders in tab 2
user clicks a link in tab 2, handler invoked, page id is changed 7
user goes back to tab 1 - that has page 5
clicks a link, handler invoked, page id changed to 8
so the graph of the page diverged and looks like this
5<-6<-7 (open in tab 2)
5<-8 (open in tab 1)
this change also eliminates the need for nasty undo objects, so where
as before we had to do:
addStateChange(new IChage() {
final int oldValue=value;
void undo() {
value=oldValue;
}
});
we can now simply say:
getPage().dirty();
pros/cons of new approach:
con: before we had to maintain just the small undo object for each
change, now we have to clone the entire page. why this doesnt matter
much? we cloned the page anyways when we stored it to disk, so there
is not that much overhead in the new scheme.
pro: undo objects gone, they were cumbersome and sometimes complicated
pro: complexity of versioning is gone
pro: version manager is gone - the thing that maintained undo objects
pro: complexity of pagemaps is gone
pro: overall simplified requirements for handling pages and therefore
simpler code in the core
hope this sums it up, probably needs to be fixed up some and then it
can go onto the wiki. looking at you jeremy :)
-igor
On Sat, Oct 16, 2010 at 8:49 PM, Jeremy Thomerson
<[email protected]> wrote:
> Has anyone written up information about the removal of page maps in 1.5? I
> have had some users asking about whether there is still multi-window
> support, and what replaced page maps in 1.5, and I couldn't find a page to
> point them to. I didn't see either of those questions answered on the wiki
> [1], and I have not dug very deeply into the internals of 1.5 myself.
>
> [1]- https://cwiki.apache.org/WICKET/migration-to-wicket-15.html
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
