You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Jeremy Thomerson <je...@wickettraining.com> on 2010/10/17 05:49:00 UTC
1.5 Page Maps
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
Re: 1.5 Page Maps
Posted by Jeremy Thomerson <je...@wickettraining.com>.
>
> hope this sums it up, probably needs to be fixed up some and then it
> can go onto the wiki. looking at you jeremy :)
>
Awesome! Very helpful!! I'll get it in the wiki sometime this week.
Thanks a ton,
--
Jeremy Thomerson
http://www.wickettraining.com
Re: 1.5 Page Maps
Posted by Martin Grigorov <mg...@apache.org>.
Hi Frank,
The locking is on page version/id.
I.e. if you request the same page instance (the same id) then the requests
will be serialized.
See org.apache.wicket.pageStore.PageAccessSynchronizerTest for more "use
cases".
On Tue, Oct 19, 2010 at 10:38 AM, Frank van Lankvelt <
f.vanlankvelt@onehippo.com> wrote:
> this question might be too detailed for a general wiki page, but I do
> wonder.
> With pagemaps gone, how is synchronisation handled?
>
> Do requests for multiple windows block each other (synchronizing on the
> session) or is the locking on page level now? (i.e. a request from tab 1,
> right after opening tab 2, waits until page 5 is cloned)
>
> thanks, Frank
>
>
> On Mon, Oct 18, 2010 at 7:02 PM, Igor Vaynberg <igor.vaynberg@gmail.com
> >wrote:
>
> > 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
> > <je...@wickettraining.com> 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
> > >
> >
>
>
>
> --
> Hippo
> Europe • Amsterdam Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20 522
> 4466
> USA • San Francisco 185 H Street Suite B • Petaluma CA 94952-5100 • +1
> (707) 773 4646
> Canada • Montréal 5369 Boulevard St-Laurent #430 • Montréal QC H2T
> 1S5 • +1 (514) 316 8966
> www.onehippo.com • www.onehippo.org • info@onehippo.com
>
Re: 1.5 Page Maps
Posted by Frank van Lankvelt <f....@onehippo.com>.
this question might be too detailed for a general wiki page, but I do
wonder.
With pagemaps gone, how is synchronisation handled?
Do requests for multiple windows block each other (synchronizing on the
session) or is the locking on page level now? (i.e. a request from tab 1,
right after opening tab 2, waits until page 5 is cloned)
thanks, Frank
On Mon, Oct 18, 2010 at 7:02 PM, Igor Vaynberg <ig...@gmail.com>wrote:
> 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
> <je...@wickettraining.com> 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
> >
>
--
Hippo
Europe • Amsterdam Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20 522
4466
USA • San Francisco 185 H Street Suite B • Petaluma CA 94952-5100 • +1
(707) 773 4646
Canada • Montréal 5369 Boulevard St-Laurent #430 • Montréal QC H2T
1S5 • +1 (514) 316 8966
www.onehippo.com • www.onehippo.org • info@onehippo.com
Re: 1.5 Page Maps
Posted by Igor Vaynberg <ig...@gmail.com>.
there is nothing wrong hosting it inside our repo from the get go as
long as you are willing to maintain it. i just meant a separate
project module.
-igor
On Mon, Oct 18, 2010 at 2:27 PM, Jeremy Thomerson
<je...@wickettraining.com> wrote:
> On Mon, Oct 18, 2010 at 4:03 PM, Igor Vaynberg <ig...@gmail.com>wrote:
>
>> yes, but *why* did you want to do this? the reasoning for all this was
>> to optimize the space usage in http session. this was legacy from
>> before the disk store days. once the disk store was introduced these
>> kinds of optimizations became obsolete.
>>
>
> There are still a few holdouts that don't (or can't) use the
> HttpSessionStore, but as you indicate below, I agree that they are the vast
> minority.
>
> i would prefer keeping all this out of the core. 99% of applications
>> that are built can support the disk store. all these optimizations are
>> only needed if you cannot support the disk store and want to store
>> everything in http session.
>>
>> what you have described sounds likely to complicate the internal quiet
>> a bit, for questionable gain.
>>
>> that said, i dont think there is anything stopping you from
>> implementing this as a separate module outside the core.
>>
>
> Agreed. If I end up tackling this, I'll start it as an outside module. If
> people express an interest in it, I can port it into our repo, but still as
> a separate submodule.
>
> --
> Jeremy Thomerson
> http://wickettraining.com
> *Need a CMS for Wicket? Use Brix! http://brixcms.org*
>
Re: 1.5 Page Maps
Posted by Jeremy Thomerson <je...@wickettraining.com>.
On Mon, Oct 18, 2010 at 4:03 PM, Igor Vaynberg <ig...@gmail.com>wrote:
> yes, but *why* did you want to do this? the reasoning for all this was
> to optimize the space usage in http session. this was legacy from
> before the disk store days. once the disk store was introduced these
> kinds of optimizations became obsolete.
>
There are still a few holdouts that don't (or can't) use the
HttpSessionStore, but as you indicate below, I agree that they are the vast
minority.
i would prefer keeping all this out of the core. 99% of applications
> that are built can support the disk store. all these optimizations are
> only needed if you cannot support the disk store and want to store
> everything in http session.
>
> what you have described sounds likely to complicate the internal quiet
> a bit, for questionable gain.
>
> that said, i dont think there is anything stopping you from
> implementing this as a separate module outside the core.
>
Agreed. If I end up tackling this, I'll start it as an outside module. If
people express an interest in it, I can port it into our repo, but still as
a separate submodule.
--
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: 1.5 Page Maps
Posted by Igor Vaynberg <ig...@gmail.com>.
On Mon, Oct 18, 2010 at 12:11 PM, Jeremy Thomerson
<je...@wickettraining.com> wrote:
> So, in looking through the code, it appears that the automatic multi-window
> support is gone (for now, at least; see http://tinyurl.com/2ut3mmd). I
> understand that a lot of it may not be needed any more because of the exact
> situation you described.
yeah, with the current versioning scheme wicket should work for
multi-window usecases out of the box.
> But, it seems that one very useful purpose of it
> is to allow you to partition the storage of pages per window, allowing X
> number of pages in session per Y windows. It also provided a convenient way
> of partitioning session data, which I never personally did, but know several
> clients who did, basically using a Map<String, SomeDataObject> where the key
> was the page map name. This provided them a sort of "conversation" scope.
not sure the valueadd here. conversational data is usually not
UI-related and most middle tier frameworks now provide it. the support
in wicket was never complete, it only worked with javascript enabled.
> Imagine that you want to allow a max of 7 pages per window, and you have the
> following flow:
>
> - start flow 1, page 1
> - go to flow 1, page 2
> - go to flow 1, page 3
> - start a subflow in a new window (flow 2, page 1)
> - go to flow 2, page 2
> - go to flow 2, page 3 (and so on for several clicks)
> - go to flow 1, page 7, where you are complete, and close the window
> - now you're back on flow 1, and want to continue to page 4, but it's
> expired because it's been at least 7 pages since you were last here
>
> Previously, you could have supported this by doing this:
>
> getSessionSettings().setMaxPageMaps(2);
> getSessionSettings().setPageMapEvictionStrategy(new
> LeastRecentlyAccessedEvictionStrategy(7));
>
yes, but *why* did you want to do this? the reasoning for all this was
to optimize the space usage in http session. this was legacy from
before the disk store days. once the disk store was introduced these
kinds of optimizations became obsolete.
> In my limited estimation, I don't think this would be extremely difficult to
> implement. With my limited knowledge of the new page manager stuff, I think
> you could do the following. Igor (or Matej), could you confirm this theory?
>
> - WebPage#PageMapChecker (linked to above) uses the same JS it was using,
> and in the listener method, instead of cloning page and moving it to the new
> page map (old functionality), it simply sets the new window name as metadata
> on the page (it should also be renamed, but that's minor).
> - the page manager keeps an internal Map<String, Collection<PageReference>>
> that represents the different windows that are open
> - wherever the expiration of old pages happens [1], you are given the
> ability to expire based on a custom strategy; one strategy that is provided
> is MaxPagesPerWindow strategy that takes X (pgs / wdw) and Y (max windows)
> [1] - From looking through the code, it appears that each IDataStore is left
> to implement this themselves. In the case of IDataStore, it does it in
> savePage(int, byte[]) by delegating to the PageWindowManager, which resets
> its pointer to the beginning of the file if you've hit X pages. For the
> proposal above, I think this would have to be abstracted out of
> PageWindowManager, and the IDataStore would ask a IExpirationStrategy if the
> page should overwrite a previous one, similar to
> what IPageMapEvictionStrategy was doing before.
>
> What are your thoughts?
> If my basic proposal above seems like it would
> work, I would like to dig in and add this feature personally. But, I want
> to run it by those who have the experience in this section of the code
> first.
i would prefer keeping all this out of the core. 99% of applications
that are built can support the disk store. all these optimizations are
only needed if you cannot support the disk store and want to store
everything in http session.
what you have described sounds likely to complicate the internal quiet
a bit, for questionable gain.
that said, i dont think there is anything stopping you from
implementing this as a separate module outside the core.
module 1 - window name module
* instantiation listener that adds a behavior to the page that checks
if the window.name has been set and if not redirects to the listener
that sets it - much like the pagemapchecker in 1.4
* window.name is stored in page metadata and is propagated from page to page.
* the behavior can also bubble a NewWindowDetected event
this would allow users to build conversation scopes
module 2 - eviction module
this can plug into module 1 and pagemanager and provide the eviction
strategy and page eviction
>
> One last question - it appears that there is no direct replacement for the
> HttpSessionStore that previously existed. There is InMemoryPageStore, but
> that isn't public, and it says it's for testing only. It seems that quite a
> few people used HttpSessionStore because of their clustering configuration
> or because of the lack of ability to write to the file system (i.e.
> AppEngine, etc). Is there a replacement for it?
i wouldnt say its quite a few, maybe a loud minority :) there is no
replacement yet, but i dont think it would be too far off from the
InMemoryPageStore, perhaps with an upper bound on the number of pages
stored.
-igor
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
> On Mon, Oct 18, 2010 at 12:02 PM, Igor Vaynberg <ig...@gmail.com>wrote:
>
>> 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
>> <je...@wickettraining.com> 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
>> >
>>
>
Re: 1.5 Page Maps
Posted by Jeremy Thomerson <je...@wickettraining.com>.
Igor, again, thanks for the great writeup. I have a few follow-up questions
for you or Matej, or anyone else who has had their hands dirty with the page
versioning / management stuff for 1.5.
So, in looking through the code, it appears that the automatic multi-window
support is gone (for now, at least; see http://tinyurl.com/2ut3mmd). I
understand that a lot of it may not be needed any more because of the exact
situation you described. But, it seems that one very useful purpose of it
is to allow you to partition the storage of pages per window, allowing X
number of pages in session per Y windows. It also provided a convenient way
of partitioning session data, which I never personally did, but know several
clients who did, basically using a Map<String, SomeDataObject> where the key
was the page map name. This provided them a sort of "conversation" scope.
Imagine that you want to allow a max of 7 pages per window, and you have the
following flow:
- start flow 1, page 1
- go to flow 1, page 2
- go to flow 1, page 3
- start a subflow in a new window (flow 2, page 1)
- go to flow 2, page 2
- go to flow 2, page 3 (and so on for several clicks)
- go to flow 1, page 7, where you are complete, and close the window
- now you're back on flow 1, and want to continue to page 4, but it's
expired because it's been at least 7 pages since you were last here
Previously, you could have supported this by doing this:
getSessionSettings().setMaxPageMaps(2);
getSessionSettings().setPageMapEvictionStrategy(new
LeastRecentlyAccessedEvictionStrategy(7));
In my limited estimation, I don't think this would be extremely difficult to
implement. With my limited knowledge of the new page manager stuff, I think
you could do the following. Igor (or Matej), could you confirm this theory?
- WebPage#PageMapChecker (linked to above) uses the same JS it was using,
and in the listener method, instead of cloning page and moving it to the new
page map (old functionality), it simply sets the new window name as metadata
on the page (it should also be renamed, but that's minor).
- the page manager keeps an internal Map<String, Collection<PageReference>>
that represents the different windows that are open
- wherever the expiration of old pages happens [1], you are given the
ability to expire based on a custom strategy; one strategy that is provided
is MaxPagesPerWindow strategy that takes X (pgs / wdw) and Y (max windows)
[1] - From looking through the code, it appears that each IDataStore is left
to implement this themselves. In the case of IDataStore, it does it in
savePage(int, byte[]) by delegating to the PageWindowManager, which resets
its pointer to the beginning of the file if you've hit X pages. For the
proposal above, I think this would have to be abstracted out of
PageWindowManager, and the IDataStore would ask a IExpirationStrategy if the
page should overwrite a previous one, similar to
what IPageMapEvictionStrategy was doing before.
What are your thoughts? If my basic proposal above seems like it would
work, I would like to dig in and add this feature personally. But, I want
to run it by those who have the experience in this section of the code
first.
One last question - it appears that there is no direct replacement for the
HttpSessionStore that previously existed. There is InMemoryPageStore, but
that isn't public, and it says it's for testing only. It seems that quite a
few people used HttpSessionStore because of their clustering configuration
or because of the lack of ability to write to the file system (i.e.
AppEngine, etc). Is there a replacement for it?
--
Jeremy Thomerson
http://www.wickettraining.com
On Mon, Oct 18, 2010 at 12:02 PM, Igor Vaynberg <ig...@gmail.com>wrote:
> 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
> <je...@wickettraining.com> 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
> >
>
Re: 1.5 Page Maps
Posted by Igor Vaynberg <ig...@gmail.com>.
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
<je...@wickettraining.com> 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
>