[wicket 1.5] removing page version manager

[igor.vaynberg]

can we yank ipageversionmanager and ichange out of 1.5? it has always
been broken because no one implements ichange objects to keep the page
state consistent.

the downside is that if someone is using httpsessionstore they will
take a bigger hit on session usage because every version is serialized
in its entirety. the up side is that it will actually work and the
code can be vastly simplified.

any concerns?

-igor

[Matej Knopp]

ipageversionmanager in 1.4 is fundamentally broken because it can only
do undo and has no redo. Plus it's pain to implement for all possible
changes so noone is really bothered to do it. the concept never worked
that's why we have snapshots in diskpagestore.

for 1.5 we should have two page stores.
DiskPageStore like one
and HttpSessionStore like one that would be non-versioned. If you
really need the raw performance of HttpSessionStore you need to give
up versioning.

Alternative of making snapshots and storing them in httpsessionstore
is no good. The main bottleneck in DiskPageStore is not writing to
disk, it's serialization. So you would lose the main benefit of
httpsessionstore (speed) and you would also lose the main benefit of
diskpagestore - free heap.

-Matej

On Fri, Oct 2, 2009 at 11:03 PM, Igor Vaynberg <igor.vaynberg@...> wrote:

> can we yank ipageversionmanager and ichange out of 1.5? it has always
> been broken because no one implements ichange objects to keep the page
> state consistent.
>
> the downside is that if someone is using httpsessionstore they will
> take a bigger hit on session usage because every version is serialized
> in its entirety. the up side is that it will actually work and the
> code can be vastly simplified.
>
> any concerns?
>
> -igor
>

[Carl-Eric Menzel-5]

On Fri, 2 Oct 2009 14:03:05 -0700
Igor Vaynberg <igor.vaynberg@...> wrote:

> can we yank ipageversionmanager and ichange out of 1.5? it has always
> been broken because no one implements ichange objects to keep the page
> state consistent.

How exactly is it broken? Just that nobody uses it, or that it actually
doesn't work, or causes more headaches than it's worth?

> the downside is that if someone is using httpsessionstore they will
> take a bigger hit on session usage because every version is serialized
> in its entirety. the up side is that it will actually work and the
> code can be vastly simplified.
>
> any concerns?

Only that I've just written a few pages about how to use it, for our
book ;-)

Carl-Eric

[igor.vaynberg]

On Fri, Oct 2, 2009 at 2:10 PM, Carl-Eric Menzel
<cm.wicket@...> wrote:
> On Fri, 2 Oct 2009 14:03:05 -0700
> Igor Vaynberg <igor.vaynberg@...> wrote:
>
>> can we yank ipageversionmanager and ichange out of 1.5? it has always
>> been broken because no one implements ichange objects to keep the page
>> state consistent.
>
> How exactly is it broken? Just that nobody uses it, or that it actually
> doesn't work, or causes more headaches than it's worth?

i would venture a guess that only about 5% of our users know what it
is, and out of those 5% only 5% bother implementing IChange objects
for all the fields on their components. and if you do not implement it
on all the fields that means your page will be in an incorrect state
when the backbutton is used.

people do not hit this problem often because diskpagestore takes a
complete snapshot and that is what 95% of our users use.

and of course about 80% of all statistics are made up.

-igor

>
>> the downside is that if someone is using httpsessionstore they will
>> take a bigger hit on session usage because every version is serialized
>> in its entirety. the up side is that it will actually work and the
>> code can be vastly simplified.
>>
>> any concerns?
>
> Only that I've just written a few pages about how to use it, for our
> book ;-)
>
> Carl-Eric
>

[Matej Knopp]

Main problem with Change is that it only can do undo. It can not do
redo which is what we need when user clicks the "Forward" browser
button. Plus wicket pages can change significantly between versions.
Representing these differences as chain of Changes is extremely
challenging if not impossible. Plus you still have to serialize model
objects, etc, which can cause another headache and it completely
ignores the rest of page state like simple class variables.

-Matej

On Fri, Oct 2, 2009 at 11:10 PM, Carl-Eric Menzel
<cm.wicket@...> wrote:

> On Fri, 2 Oct 2009 14:03:05 -0700
> Igor Vaynberg <igor.vaynberg@...> wrote:
>
>> can we yank ipageversionmanager and ichange out of 1.5? it has always
>> been broken because no one implements ichange objects to keep the page
>> state consistent.
>
> How exactly is it broken? Just that nobody uses it, or that it actually
> doesn't work, or causes more headaches than it's worth?
>
>> the downside is that if someone is using httpsessionstore they will
>> take a bigger hit on session usage because every version is serialized
>> in its entirety. the up side is that it will actually work and the
>> code can be vastly simplified.
>>
>> any concerns?
>
> Only that I've just written a few pages about how to use it, for our
> book ;-)
>
> Carl-Eric
>

[Carl-Eric Menzel-5]

On Fri, 2 Oct 2009 23:15:56 +0200
Matej Knopp <matej.knopp@...> wrote:

> Main problem with Change is that it only can do undo. It can not do
> redo which is what we need when user clicks the "Forward" browser
> button. Plus wicket pages can change significantly between versions.
> Representing these differences as chain of Changes is extremely
> challenging if not impossible. Plus you still have to serialize model
> objects, etc, which can cause another headache and it completely
> ignores the rest of page state like simple class variables.

Okay, I understand this. I guess I'll have to tear a few pages out of
the book ;-)

How does the back button support work then - when an older version of
the page is loaded, the component state is restored as it was, since it
was all serialized. Is this all mostly for allowing stuff like
Link#onClick() to work on old page versions? How do you avoid running
into problems when you have, for example, LoadableDetachableModels and
you have changed your domain objects. Or you have changed something not
under control of the Page, some sort of application state. Would there
be no undo mechanism at all then? At least in principle I liked the
idea of simply handing Wicket a couple of undo operations. Is it
possible to be notified when an old page version is loaded? That way
one could in principle build a custom undo.

Carl-Eric

PS: I hope I wrote my questions clearly, it's a bit late here already...

[Matej Knopp]

On Fri, Oct 2, 2009 at 11:29 PM, Carl-Eric Menzel
<cm.wicket@...> wrote:

> On Fri, 2 Oct 2009 23:15:56 +0200
> Matej Knopp <matej.knopp@...> wrote:
>
>> Main problem with Change is that it only can do undo. It can not do
>> redo which is what we need when user clicks the "Forward" browser
>> button. Plus wicket pages can change significantly between versions.
>> Representing these differences as chain of Changes is extremely
>> challenging if not impossible. Plus you still have to serialize model
>> objects, etc, which can cause another headache and it completely
>> ignores the rest of page state like simple class variables.
>
> Okay, I understand this. I guess I'll have to tear a few pages out of
> the book ;-)
>
> How does the back button support work then - when an older version of
> the page is loaded, the component state is restored as it was, since it
> was all serialized. Is this all mostly for allowing stuff like
> Link#onClick() to work on old page versions? How do you avoid running
> into problems when you have, for example, LoadableDetachableModels and
> you have changed your domain objects. Or you have changed something not
> under control of the Page, some sort of application state. Would there
> be no undo mechanism at all then? At least in principle I liked the
> idea of simply handing Wicket a couple of undo operations. Is it
> possible to be notified when an old page version is loaded? That way
> one could in principle build a custom undo.

Wicket version management is concerned with components. We don't
version your domain objects (unless you keep hard references to them
and they get serialized with the page). If you are using models
properly most of the time when you deserialize and render the page
your entities get reloaded so user sees the current state of your
domain objects.

-Matej

>
> Carl-Eric
>
> PS: I hope I wrote my questions clearly, it's a bit late here already...
>

[Carl-Eric Menzel-5]

> Wicket version management is concerned with components. We don't
> version your domain objects (unless you keep hard references to them
> and they get serialized with the page). If you are using models
> properly most of the time when you deserialize and render the page
> your entities get reloaded so user sees the current state of your
> domain objects.

Yes I know that it's about components. I was just wondering whether
custom undo is going to be lost completely, or whether there will be
ways to react to the user "going back in time".

Or are you saying this should all be done in Models? Of course, on the
other hand I'm wondering how much undo is possible anyway in a web
environment, even with a mechanism such as Change objects.

Carl-Eric

[Johan Compagner]

I dont think thats to much of a problem but do think about that also the
DiskStore is using it to generate its versions for the pages
see SecondLevelCachePageVersionManager

So we still need something that generates a version number...

On Fri, Oct 2, 2009 at 23:03, Igor Vaynberg <igor.vaynberg@...> wrote:

> can we yank ipageversionmanager and ichange out of 1.5? it has always
> been broken because no one implements ichange objects to keep the page
> state consistent.
>
> the downside is that if someone is using httpsessionstore they will
> take a bigger hit on session usage because every version is serialized
> in its entirety. the up side is that it will actually work and the
> code can be vastly simplified.
>
> any concerns?
>
> -igor
>

[Matej Knopp]

We don't. My experimental branch only has page id. Instead of
incrementing version number I just increment page Id.

-Matej

On Mon, Oct 5, 2009 at 4:47 PM, Johan Compagner <jcompagner@...> wrote:

> I dont think thats to much of a problem but do think about that also the
> DiskStore is using it to generate its versions for the pages
> see SecondLevelCachePageVersionManager
>
> So we still need something that generates a version number...
>
> On Fri, Oct 2, 2009 at 23:03, Igor Vaynberg <igor.vaynberg@...> wrote:
>
>> can we yank ipageversionmanager and ichange out of 1.5? it has always
>> been broken because no one implements ichange objects to keep the page
>> state consistent.
>>
>> the downside is that if someone is using httpsessionstore they will
>> take a bigger hit on session usage because every version is serialized
>> in its entirety. the up side is that it will actually work and the
>> code can be vastly simplified.
>>
>> any concerns?
>>
>> -igor
>>
>

[Johan Compagner]

i have to look at the code. (been 4 days in barcelona so not online that
much)
but i guess you increment the page id by asking the session? (and not just
pageid++)

but yes in the diskstore we only need 1 unique (session) id per page
version.

johan


On Mon, Oct 5, 2009 at 16:54, Matej Knopp <matej.knopp@...> wrote:

> We don't. My experimental branch only has page id. Instead of
> incrementing version number I just increment page Id.
>
> -Matej
>
> On Mon, Oct 5, 2009 at 4:47 PM, Johan Compagner <jcompagner@...>
> wrote:
> > I dont think thats to much of a problem but do think about that also the
> > DiskStore is using it to generate its versions for the pages
> > see SecondLevelCachePageVersionManager
> >
> > So we still need something that generates a version number...
> >
> > On Fri, Oct 2, 2009 at 23:03, Igor Vaynberg <igor.vaynberg@...>
> wrote:
> >
> >> can we yank ipageversionmanager and ichange out of 1.5? it has always
> >> been broken because no one implements ichange objects to keep the page
> >> state consistent.
> >>
> >> the downside is that if someone is using httpsessionstore they will
> >> take a bigger hit on session usage because every version is serialized
> >> in its entirety. the up side is that it will actually work and the
> >> code can be vastly simplified.
> >>
> >> any concerns?
> >>
> >> -igor
> >>
> >
>

[Matej Knopp]

Yes, page ids are unique within session. I don't think the branch
actually increments page Id anywhere, so far It's more like a concept.
The reason why it doesn't version pages yet is that pages and
components are only mocked at this point. The branch demonstrates new
request processing and request cycle. Pages and components are just
simple, rather dummy implementations.

-Matej

On Mon, Oct 5, 2009 at 5:02 PM, Johan Compagner <jcompagner@...> wrote:

> i have to look at the code. (been 4 days in barcelona so not online that
> much)
> but i guess you increment the page id by asking the session? (and not just
> pageid++)
>
> but yes in the diskstore we only need 1 unique (session) id per page
> version.
>
> johan
>
>
> On Mon, Oct 5, 2009 at 16:54, Matej Knopp <matej.knopp@...> wrote:
>
>> We don't. My experimental branch only has page id. Instead of
>> incrementing version number I just increment page Id.
>>
>> -Matej
>>
>> On Mon, Oct 5, 2009 at 4:47 PM, Johan Compagner <jcompagner@...>
>> wrote:
>> > I dont think thats to much of a problem but do think about that also the
>> > DiskStore is using it to generate its versions for the pages
>> > see SecondLevelCachePageVersionManager
>> >
>> > So we still need something that generates a version number...
>> >
>> > On Fri, Oct 2, 2009 at 23:03, Igor Vaynberg <igor.vaynberg@...>
>> wrote:
>> >
>> >> can we yank ipageversionmanager and ichange out of 1.5? it has always
>> >> been broken because no one implements ichange objects to keep the page
>> >> state consistent.
>> >>
>> >> the downside is that if someone is using httpsessionstore they will
>> >> take a bigger hit on session usage because every version is serialized
>> >> in its entirety. the up side is that it will actually work and the
>> >> code can be vastly simplified.
>> >>
>> >> any concerns?
>> >>
>> >> -igor
>> >>
>> >
>>
>