Mailing-List: contact dev-help@wicket.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@wicket.apache.org
Received-SPF: pass (nike.apache.org: domain of matej.knopp@gmail.com
 designates 209.85.218.225 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=l/NjYZqjvebwx5YWo9CAEUOERba+Jzlyw22tjRBJ5KdX6ZzwffwlR0Gi1O5AFMrnvn
         CCYwGXG4QxInKE6jfYoWmWWIJnUHMy5adFPhpt446jRbmGrjfYrGggYoe8N9cnav2w6F
         7xUHv4PpKKw/ipPWFQCtXdaPz5vsDFlMNeVnI=
MIME-Version: 1.0
In-Reply-To: <20091002231058.6f16c2a4@gutenbook>
References: <23eb48360910021403n51a98129sca687aaadcafece6@mail.gmail.com>
	<20091002231058.6f16c2a4@gutenbook>
From: Matej Knopp <matej.knopp@gmail.com>
Date: Fri, 2 Oct 2009 23:15:56 +0200
Message-ID: <109027740910021415i16f530c5y9cf37c9cdda1aa7f@mail.gmail.com>
Subject: Re: [wicket 1.5] removing page version manager
To: dev@wicket.apache.org
Content-Type: text/plain; charset=ISO-8859-1

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@users.bitforce.com> wrote:
> On Fri, 2 Oct 2009 14:03:05 -0700
> Igor Vaynberg <igor.vaynberg@gmail.com> 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
>