turning off page versioning

[Garret Wilson <ga...@globalmentor.com>]

Can someone explain to me exactly how page versioning works, and how to 
turn it off?

I have a page StagingPage that contains a file uploader. This page is 
interesting in that when you upload some files with Button1, the page 
lists the files on the page and keeps them in a collection until you hit 
Button2, at which point the pages does Some Other Really Interesting 
Thing with the files. In other words, the page acts like a staging area 
for files, allowing you to 1) upload files and then 2) do something with 
them.

I get this number on the end of the URLs which, from the page versioning 
and caching reference documentation 
<http://wicket.apache.org/guide/guide/versioningCaching.html>, seems to 
indicate the version of the page. I don't want this. I just want there 
to be one version of the page (even though it is stateful). The back 
button can go to the previous page; I don't care.

So I turn off versioning in StagingPage with:

    setVersioned(false);


But I still get numbers at the end of the StagingPage URL. Worse, back 
and forward in my browser goes between apparently two versions of the 
page (one with the "Choose Files" button selecting files, and one 
without)---but the number in the URL doesn't change! Worse still, when I 
remove the number and reload the URL without the number, Wicket puts the 
number back but first increments the number! Now back and forward cycle 
between numbered URLs.

I thought setVersioned(false) was supposed to turn all that off?

In my own Guise framework, each page has a single component instance 
tree on the back end. Whatever you do at that URL, whenever you come 
back to it it will be just like you left it. Granted, there are several 
drawbacks such as memory consumption; Guise can learn a lot from Wicket 
in how the latter can serialize each page between requests, and 
versioning can be very useful in some situations. But here I just want a 
stateful page that has one single version---the current version. I don't 
want it to remember any previous versions. And I don't want numbers on 
the end of the URL. How can I turn off versioning for real?

Thanks,

Garret

Re: turning off page versioning

[Maxim Solodovnik <so...@gmail.com>]

In our project we are using NoVersionRequestMapper to create user friendly
URLs
seems to work as expected

On 23 September 2014 20:44, Garret Wilson <ga...@globalmentor.com> wrote:

> OMG. What a sad email to wake up to. :(
>
> Let me let all that digest for a while. I never would have imagined a
> situation this dire. Imagine if every time you went to Facebook, it
> generated a new https://www.facebook.com/jdoe?124154451 version! So
> basically Facebook could never use Wicket without rewriting the whole page
> caching scheme. Or LinkedIn. Or... actually, come to think of it, I can't
> even think of a single site that functions like Wicket, incrementing some
> "page version" counter every time you interact with the page, so that you
> can go back to other "versions". (Users don't want to go back to other
> versions! They may want to go back to other /pages/ at different URLs, but
> they realize that interacting with a single pages changes the state of that
> page---they don't expect that other "versions" are kept around somewhere.)
>
> Continuing my scenario I outlined earlier, I have an HTML page called
> MenuPage, which has <wicket:link><a href="StagingPage.html">..., the target
> page of which functions as I explained below. Every time the user goes to
> the MenuPage and clicks on the link, you're saying that Wicket will
> generate a new version of StagingPage in the cache, even with
> setVersioned(false)? It will generate a new ...StagingPage.html?23423414
> URL? There is no way to turn that off... without essentially rewriting the
> whole Wicket page request and caching mechanism??
>
> This is not good news. I'm not ranting, I'm crying.
>
> Garret
>
> On 9/23/2014 8:24 AM, Martin Grigorov wrote:
>
>> Hi,
>>
>> In short, to accomplish all this you will need several custom impls of
>> Wicket interfaces.
>> 1) custom IRequestMapper that just ignores PageInfo when generating the
>> url
>> for IPageRequestHandler. Search in the archives for
>> "NoVersionRequestMapper"
>> 2) a completely new IPageManager (interface!) that works with Class<Page>
>> instead of with Integer (pageId)
>> So everytime a url is mapped to a page class you should use it to load the
>> Page instance for this class
>>
>> In details:
>> By design only stateless pages do not have the pageId in the url! If a
>> request without pageId comes then a completely new page instance is
>> created.
>> By using something like NoVersionRequestMapper (not supported officially!)
>> only the url for the browser address bar will miss the pageId (see
>> PageAndComponentInfo class), but the pageId is in all link/form urls so
>> clicking/submitting still works. But if the user refreshes the page (F5)
>> then the state is lost!
>>
>> About Page#setVersioned(boolean)
>> This tells Wicket to not increment the pageId after an interaction with
>> the
>> page. A pageId is associated with the page when it is instantiated, but
>> any
>> link click, form submit, etc. won't create a new version of the page. The
>> final result is that every interaction (i.e. state change) with the page
>> will lead to overriding the old one in the page stores.
>> Wicket's IPageStore/IDataStore use API like: put(String sessionId, int
>> pageId, byte[] serializedPage). At the end of every request cycle all
>> rendered stateful pages are stored. If the pageId doesn't change then some
>> old serializedPage would be overriden.
>>
>> For your requirements you will need an API like: put(String sessionId,
>> Class<Page> pageClass, byte[] serializedPage) and byte [] get(String
>> sessionId, Class<Page> pageClass).
>> You can create a IPageManager wrapper that maps sessionId+pageId to
>> pageClass and use that pageClass with custom IMyPageStore and IMyDataStore
>> impls. (Just an idea out of my mind.)
>>
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Tue, Sep 23, 2014 at 3:42 AM, Garret Wilson <ga...@globalmentor.com>
>> wrote:
>>
>>  Can someone explain to me exactly how page versioning works, and how to
>>> turn it off?
>>>
>>> I have a page StagingPage that contains a file uploader. This page is
>>> interesting in that when you upload some files with Button1, the page
>>> lists
>>> the files on the page and keeps them in a collection until you hit
>>> Button2,
>>> at which point the pages does Some Other Really Interesting Thing with
>>> the
>>> files. In other words, the page acts like a staging area for files,
>>> allowing you to 1) upload files and then 2) do something with them.
>>>
>>> I get this number on the end of the URLs which, from the page versioning
>>> and caching reference documentation <http://wicket.apache.org/
>>> guide/guide/versioningCaching.html>, seems to indicate the version of
>>> the
>>> page. I don't want this. I just want there to be one version of the page
>>> (even though it is stateful). The back button can go to the previous
>>> page;
>>> I don't care.
>>>
>>> So I turn off versioning in StagingPage with:
>>>
>>>     setVersioned(false);
>>>
>>>
>>> But I still get numbers at the end of the StagingPage URL. Worse, back
>>> and
>>> forward in my browser goes between apparently two versions of the page
>>> (one
>>> with the "Choose Files" button selecting files, and one without)---but
>>> the
>>> number in the URL doesn't change! Worse still, when I remove the number
>>> and
>>> reload the URL without the number, Wicket puts the number back but first
>>> increments the number! Now back and forward cycle between numbered URLs.
>>>
>>> I thought setVersioned(false) was supposed to turn all that off?
>>>
>>> In my own Guise framework, each page has a single component instance tree
>>> on the back end. Whatever you do at that URL, whenever you come back to
>>> it
>>> it will be just like you left it. Granted, there are several drawbacks
>>> such
>>> as memory consumption; Guise can learn a lot from Wicket in how the
>>> latter
>>> can serialize each page between requests, and versioning can be very
>>> useful
>>> in some situations. But here I just want a stateful page that has one
>>> single version---the current version. I don't want it to remember any
>>> previous versions. And I don't want numbers on the end of the URL. How
>>> can
>>> I turn off versioning for real?
>>>
>>> Thanks,
>>>
>>> Garret
>>>
>>>
>


-- 
WBR
Maxim aka solomax

Re: turning off page versioning

[Thibault Kruse <ti...@googlemail.com>]

No, I believe what Wicket currently does is okay, but in web projects
with wicket, when page versioning is a problem (e.g. because of the
number apearing in the url, or any other issue with it), then it is
commonly dealt with much too late.

Too late means that application pages will already be filled with
components and navigation logic that require page versioning, so that
there cannot be an easy off-switch for page versioning that does not
also break functionality. Replacing the mechanisms then one by one
means an unnecessary additional development effort compared to having
considered what pages should not be versioned from the start.

I have not enough insight to have an opinion about what wicket could
do to help with situations where projects have gone on for some time
without care for page versioning, and at that point the requirement to
not have page numbers (and not needs prior versions of pages) becomes
relevant.


On Wed, Sep 24, 2014 at 11:34 AM, Martin Grigorov <mg...@apache.org> wrote:
> Thibault,
>
> On Wed, Sep 24, 2014 at 11:23 AM, Thibault Kruse <ti...@googlemail.com>
> wrote:
>
>> On Wed, Sep 24, 2014 at 2:13 AM, Garret Wilson <ga...@globalmentor.com>
>> wrote:
>> > I'm not denying that versioned pages may be a useful concept for some use
>> > cases (even though I can't think of any offhand). I'm just saying it's
>> not
>> > my use case, and I had assumed throughout development on our project
>> that I
>> > could just turn it off by calling setVersioned(false).
>>
>> Maybe that is the biggest problem with page versioning in a wicket
>> project. As a symptom it is annoying to understand and circumvent, and
>> it seems like just a minor configuration thing, so projects advance
>> leaving the undesired page version as "something to be fixed later"
>> using the full set of features and component relying on page
>> versioning. Then much later in the project, they find out that it's
>> not easy to get rid of page versioning without paying a hefty price.
>>
>
> Do you say that Wicket should store only one page instance per user session
> ? (As Garret's usecase)
> Or that it should not create separate versions for interactions like link
> click ? (PageSettings#setVersionPagesByDefault(false))
> Or just that the ?pageId in the url is something that should be possible to
> be removed if the application developer says it is OK ?
>
>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: turning off page versioning

[Martin Grigorov <mg...@apache.org>]

Thibault,

On Wed, Sep 24, 2014 at 11:23 AM, Thibault Kruse <ti...@googlemail.com>
wrote:

> On Wed, Sep 24, 2014 at 2:13 AM, Garret Wilson <ga...@globalmentor.com>
> wrote:
> > I'm not denying that versioned pages may be a useful concept for some use
> > cases (even though I can't think of any offhand). I'm just saying it's
> not
> > my use case, and I had assumed throughout development on our project
> that I
> > could just turn it off by calling setVersioned(false).
>
> Maybe that is the biggest problem with page versioning in a wicket
> project. As a symptom it is annoying to understand and circumvent, and
> it seems like just a minor configuration thing, so projects advance
> leaving the undesired page version as "something to be fixed later"
> using the full set of features and component relying on page
> versioning. Then much later in the project, they find out that it's
> not easy to get rid of page versioning without paying a hefty price.
>

Do you say that Wicket should store only one page instance per user session
? (As Garret's usecase)
Or that it should not create separate versions for interactions like link
click ? (PageSettings#setVersionPagesByDefault(false))
Or just that the ?pageId in the url is something that should be possible to
be removed if the application developer says it is OK ?


>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Re: turning off page versioning

[Thibault Kruse <ti...@googlemail.com>]

On Wed, Sep 24, 2014 at 2:13 AM, Garret Wilson <ga...@globalmentor.com> wrote:
> I'm not denying that versioned pages may be a useful concept for some use
> cases (even though I can't think of any offhand). I'm just saying it's not
> my use case, and I had assumed throughout development on our project that I
> could just turn it off by calling setVersioned(false).

Maybe that is the biggest problem with page versioning in a wicket
project. As a symptom it is annoying to understand and circumvent, and
it seems like just a minor configuration thing, so projects advance
leaving the undesired page version as "something to be fixed later"
using the full set of features and component relying on page
versioning. Then much later in the project, they find out that it's
not easy to get rid of page versioning without paying a hefty price.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: turning off page versioning

[Garret Wilson <ga...@globalmentor.com>]

On 9/24/2014 4:28 AM, Martin Grigorov wrote:
> ...
> > Apparently Wicket thinks the browser "back" button is an "undo" button.
> > But in my mind it's not---it's a "back" button that goes to the previous
> > page. If you're still on the same page but you've changed that page, then
> > you see the new version of the page!
>
> This is not 100% correct.
> Going back will tell Wicket to load some previous page version. But it is
> your code logic that decides what to show. If you use dynamic model then
> you will ask the DB whether the current user is a friend with Jane Doe and
> it will return the current state of affairs.
> Wicket renders pages with cache disabled so #onConfigure, #onBeforeRender,
> #onRender, #onAfterRender, onDetach are called and your application logic
> decides what exactly to render.

So you're saying that if I'm careful to use all dynamic models (even 
overriding isVisible() for components to dynamically query whether they 
should be visible), then my web application will wind up with many 
versions of the same page serialized on disk somewhere, all with 
different URL queries, and the user can navigate among them, but when 
rendered they will all show 100% the same data?

Yeah, I definitely want to turn that off.

Garret

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: turning off page versioning

[Martin Grigorov <mg...@apache.org>]

Hi,

On Wed, Sep 24, 2014 at 2:13 AM, Garret Wilson <ga...@globalmentor.com>
wrote:

> On 9/23/2014 12:08 PM, Martin Grigorov wrote:
>
>> On Tue, Sep 23, 2014 at 4:44 PM, Garret Wilson <ga...@globalmentor.com>
>> wrote:
>>
>>  OMG. What a sad email to wake up to. :(
>>>
>>> Let me let all that digest for a while. I never would have imagined a
>>> situation this dire. Imagine if every time you went to Facebook, it
>>> generated a new https://www.facebook.com/jdoe?124154451 version! So
>>> basically Facebook could never use Wicket without rewriting the whole
>>> page
>>> caching scheme. Or
>>>
>>
>> this particular url (https://www.facebook.com/jdoe?124154451) returns
>> 404,
>> but otherwise Facebook renders completely different content on page
>> refresh
>> (and I'm OK with that!)
>>
>
> Ah, I wasn't clear. I meant, imagine if Facebook was running on Wicket.
> Each time you go to https://www.facebook.com/jdoe, it would redirect you
> to https://www.facebook.com/jdoe?1. Imagine if you went there again and
> it redirected you to https://www.facebook.com/jdoe?2. Imagine if you
> clicked "Like" on somebody's picture, and it redirectred you to
> https://www.facebook.com/jdoe?3. But it still kept
> https://www.facebook.com/jdoe?2 in memory, so that when you hit "Back"
> you'd see the picture before you liked it. Soon you'd have
> https://www.facebook.com/jdoe?124154451...
>
>  What is the actual problem ?
>> The number in the url ?
>>
>
> Yes.
>
>  Or that a new page instance is created ?
>>
>
> ...and yes.
>
> And both of those together cause even more problems, because not only are
> new page instances created, the user can navigate among them.
>
> I'm not denying that versioned pages may be a useful concept for some use
> cases (even though I can't think of any offhand). I'm just saying it's not
> my use case, and I had assumed throughout development on our project that I
> could just turn it off by calling setVersioned(false). Your email this
> morning informed me that I had been under an incorrect assumption, and that
> made me sad.
>
>
>
>> Imagine this:
>> PageA initial state renders PanelA and a LinkA.
>> Clicking on LinkA PanelA is replaced with PanelB.
>>
>> case 1) with the pageId in the url if you refresh the page then you will
>> still see PanelB in the page
>> case 2) without the pageId you will see PanelA, because a new page
>> instance
>> is created
>>
>> Now imagine that Wicket stores pages by type.
>>
>
> It's not necessarily by type---it's by mounted URL. Maybe you mount the
> same type at various URLs; they would all be kept track of separately. This
> is how Guise does it. (I'm not saying "Oh, Guise is better than
> everything." I'm just using it as an example reference here. It does some
> things better. It does some things worse. It functions like I'm describing
> now because that's the only thing I thought of when I wrote it.) Each mount
> point has a single version that is changed as the user interacts with it.
> Granted, this causes some problems when multiple browser tabs are opened
> with the same page; in the future I hope to address this, but it's not
> trivial. Guise started out with the assumption that the user would only
> have one tab opened for a page.
>
> But in this example, yeah, a Wicket page "type" equates to a single URL
> mount point. I was being pedantic.
>
>
>    Once the user clicks LinkA
>> how (s)he will be able to see the initial state with PanelA again ?
>>
>
> Why would the user expect or want to see PanelA again? Didn't (s)he just
> click on the link that said "remove panel A and add panel B?" If the user
> wants to see PanelA again, (s)he clicks on the link that says "put panel A
> back!"
>
> Apparently Wicket thinks the browser "back" button is an "undo" button.
> But in my mind it's not---it's a "back" button that goes to the previous
> page. If you're still on the same page but you've changed that page, then
> you see the new version of the page!
>

This is not 100% correct.
Going back will tell Wicket to load some previous page version. But it is
your code logic that decides what to show. If you use dynamic model then
you will ask the DB whether the current user is a friend with Jane Doe and
it will return the current state of affairs.
Wicket renders pages with cache disabled so #onConfigure, #onBeforeRender,
#onRender, #onAfterRender, onDetach are called and your application logic
decides what exactly to render.


>
> Imagine that you're on Facebook, and you click on the button that says
> "unfriend Jane Doe" (that is, don't be friends anymore with Jane Doe). What
> happens when you hit the back button? Do you expect to get Jane Doe back as
> a friend?
>
> Hahahah! Sorry, please forgive me for laughing at my own example. It's
> been a long, exhausting day---allow me a bit of humor before heading to bed.
>

Then sorry for spoiling your fun :-)


>
> Anyway, I hope you see my point. Like I said, maybe versioning has its use
> cases. It's just not /my/ use case, and I want to turn it off.
>

I see your point. Another user recently also tried to explain similar needs
like yours.


>
> Best,
>
> Garret
>

Re: turning off page versioning

[ChambreNoire <aw...@tentelemed.com>]

ok but it has only started happening since I added the single-page-instance
code...

--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/turning-off-page-versioning-tp4667631p4668679.html
Sent from the Users forum mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: turning off page versioning

[Martin Grigorov <mg...@apache.org>]

This could happen even in a normal Wicket application.

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Mon, Dec 8, 2014 at 2:37 PM, ChambreNoire <aw...@tentelemed.com> wrote:

> Hmm it's no really working for me. Occassionally ajax links within the
> single
> page cause a StalePageException which results in a refresh but without the
> expected panel change normally caused by the link which is jarring..
>
> Any ideas?
>
> CN
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/turning-off-page-versioning-tp4667631p4668677.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Re: turning off page versioning

[ChambreNoire <aw...@tentelemed.com>]

Hmm it's no really working for me. Occassionally ajax links within the single
page cause a StalePageException which results in a refresh but without the
expected panel change normally caused by the link which is jarring..

Any ideas?

CN

--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/turning-off-page-versioning-tp4667631p4668677.html
Sent from the Users forum mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: turning off page versioning

[Martin Grigorov <mg...@apache.org>]

The magic happens in WebPageRenderer#respond() method.
But beware that this is one of the most scary (to reason about) code in
Wicket. We know about this problem, we simplified it somehow for Wicket 7,
but still as the comments there say "it is hairy".

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Fri, Sep 26, 2014 at 1:48 PM, mscoon <ms...@gmail.com> wrote:

> One last question: what code is involved in the redirect to buffer
> strategy? Where to start to search if using the NoVersionMapper without the
> SinglePageManager will have problems with redirect to buffer?
>
> Thanks a lot for your time so far. As always you rock (and so does the
> list) :)
>
> On Fri, Sep 26, 2014 at 2:16 PM, Martin Grigorov <mg...@apache.org>
> wrote:
>
> > Thanks for testing!
> > I'm sure there will be problems to be solved.
> > The app is just a proof of concept that it is not that hard to accomplish
> > what Garret wanted.
> > If someone wants to use this in production then (s)he will have to test
> and
> > optimize it further.
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
> >
> > On Fri, Sep 26, 2014 at 12:58 PM, mscoon <ms...@gmail.com> wrote:
> >
> > > I just tried your demo, it does seem to redirect (the requested url is
> ?0
> > > while the current url has no version number)...
> > >
> > > But I was referring to the use of NoVersionMapper without
> > > SinglePageManager. I tried this too, and redirect to render breaks
> > because
> > > the redirect is to http://blahblah/a and has no way of knowing which
> > > version should be used.
> > >
> > > Redirect to buffer apparently works because the response was buffered
> > > during the initial request that did include a page version in the url.
> > >
> > > On Fri, Sep 26, 2014 at 1:34 PM, Martin Grigorov <mgrigorov@apache.org
> >
> > > wrote:
> > >
> > > > On Fri, Sep 26, 2014 at 12:23 PM, mscoon <ms...@gmail.com> wrote:
> > > >
> > > > > Okay I see.
> > > > >
> > > > > I imagine this approach breaks if the render strategy is
> > > > REDIRECT_TO_RENDER
> > > > > and works in ONE_PASS_RENDER and REDIRECT_TO_BUFFER.
> > > > >
> > > >
> > > > Wicket will redirect only if the requested url differs with the
> > response
> > > > url.
> > > > Since the ?pageId is not in the url anymore then it depends only on
> the
> > > > page parameters.
> > > > As you can see in the demo app I haven't played with this.
> > > >
> > > >
> > > > >
> > > > > Also REDIRECT_TO_BUFFER works sort of by chance? What would happen
> if
> > > > > somehow requests from different tabs for the same page (url) were
> > > handled
> > > > > simultaneously?
> > > > >
> > > >
> > > > Wicket serializes the access to page instance. Since there is only
> one
> > > page
> > > > instance per type then multitab support is more limited than current
> > > > Wicket.
> > > > Request1 will acquire the permit to use the page instance and
> request2
> > > will
> > > > wait on PageAccessSynchronizer. Once request1 finishes then if it is
> > Ajax
> > > > then all as before/now. But if request1 is normal (non-Ajax) then
> > > > page#renderCount will be incremented and request2 will fail will
> > > > StalePageException and just re-render with the last state (the one
> > after
> > > > request1). So you may see more "do-nothing" interactions with the
> page
> > > than
> > > > now.
> > > >
> > > >
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Sep 26, 2014 at 11:58 AM, Martin Grigorov <
> > > mgrigorov@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > What you describe is what several users currently do by using
> > > > > > NoVersionMapper.
> > > > > > NoVersionMapper is the thing that hides the ?pageId from the url
> in
> > > the
> > > > > > address bar.
> > > > > >
> > > > > > The changes you suggest to be done in SinglePageManager
> > (effectively
> > > > > remove
> > > > > > SinglePageManager completely) is the current default behavior in
> > > > Wicket.
> > > > > >
> > > > > > The "hole" is that F5 (page refresh) loses the state and creates
> a
> > > > > > completely new page instance with its own state. Using
> back/forward
> > > > will
> > > > > > lose the state too.
> > > > > > This is the reason why NoVersionMapper is not in the official
> > Wicket
> > > > > > distro.
> > > > > >
> > > > > > Martin Grigorov
> > > > > > Wicket Training and Consulting
> > > > > > https://twitter.com/mtgrigorov
> > > > > >
> > > > > > On Fri, Sep 26, 2014 at 10:52 AM, mscoon <ms...@gmail.com>
> wrote:
> > > > > >
> > > > > > > Martin,
> > > > > > >
> > > > > > > I found you "single-page-instance" sample very interesting.
> > > > > > >
> > > > > > > I have the following question if you can spare some time:
> > > > > > >
> > > > > > > What happens if you completely remove the local map in
> > > > > SinglePageManager
> > > > > > > (and the associated) code?
> > > > > > >
> > > > > > > I.e. if SinglePageManager#getPage(int id) always delegates to
> the
> > > > > > > underlying manager and SinglePageManager#newPage() always
> > returns a
> > > > new
> > > > > > > page from the underlying factory.
> > > > > > >
> > > > > > > It seems that then you get the following:
> > > > > > > 1. Every time you hit a page either by url or navigation, you
> > get a
> > > > > fresh
> > > > > > > instance, but without a version parameter in the url.
> Effectively
> > > you
> > > > > > get a
> > > > > > > new version of the page but the url does not include the
> version
> > > > > number.
> > > > > > > 2. Interactions with the page affect the specific version. As
> > long
> > > as
> > > > > you
> > > > > > > keep interacting with the page (e.g. "Increment"), you are
> fine.
> > > You
> > > > > can
> > > > > > > even have the same page in two tabs with different state.
> > > > > > > 3. If you hit F5 you go back to the page's original state
> > > > > > >
> > > > > > > I think the behavior outlined above is also valid for several
> use
> > > > cases
> > > > > > > (e.g. facebook's profile page works like this - there are a lot
> > of
> > > > ajax
> > > > > > > interactions but if you hit F5 you go back to the page's
> original
> > > > > state).
> > > > > > >
> > > > > > > Do you see any holes?
> > > > > > >
> > > > > > > Thanks
> > > > > > > Marios
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: turning off page versioning

[mscoon <ms...@gmail.com>]

One last question: what code is involved in the redirect to buffer
strategy? Where to start to search if using the NoVersionMapper without the
SinglePageManager will have problems with redirect to buffer?

Thanks a lot for your time so far. As always you rock (and so does the
list) :)

On Fri, Sep 26, 2014 at 2:16 PM, Martin Grigorov <mg...@apache.org>
wrote:

> Thanks for testing!
> I'm sure there will be problems to be solved.
> The app is just a proof of concept that it is not that hard to accomplish
> what Garret wanted.
> If someone wants to use this in production then (s)he will have to test and
> optimize it further.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Fri, Sep 26, 2014 at 12:58 PM, mscoon <ms...@gmail.com> wrote:
>
> > I just tried your demo, it does seem to redirect (the requested url is ?0
> > while the current url has no version number)...
> >
> > But I was referring to the use of NoVersionMapper without
> > SinglePageManager. I tried this too, and redirect to render breaks
> because
> > the redirect is to http://blahblah/a and has no way of knowing which
> > version should be used.
> >
> > Redirect to buffer apparently works because the response was buffered
> > during the initial request that did include a page version in the url.
> >
> > On Fri, Sep 26, 2014 at 1:34 PM, Martin Grigorov <mg...@apache.org>
> > wrote:
> >
> > > On Fri, Sep 26, 2014 at 12:23 PM, mscoon <ms...@gmail.com> wrote:
> > >
> > > > Okay I see.
> > > >
> > > > I imagine this approach breaks if the render strategy is
> > > REDIRECT_TO_RENDER
> > > > and works in ONE_PASS_RENDER and REDIRECT_TO_BUFFER.
> > > >
> > >
> > > Wicket will redirect only if the requested url differs with the
> response
> > > url.
> > > Since the ?pageId is not in the url anymore then it depends only on the
> > > page parameters.
> > > As you can see in the demo app I haven't played with this.
> > >
> > >
> > > >
> > > > Also REDIRECT_TO_BUFFER works sort of by chance? What would happen if
> > > > somehow requests from different tabs for the same page (url) were
> > handled
> > > > simultaneously?
> > > >
> > >
> > > Wicket serializes the access to page instance. Since there is only one
> > page
> > > instance per type then multitab support is more limited than current
> > > Wicket.
> > > Request1 will acquire the permit to use the page instance and request2
> > will
> > > wait on PageAccessSynchronizer. Once request1 finishes then if it is
> Ajax
> > > then all as before/now. But if request1 is normal (non-Ajax) then
> > > page#renderCount will be incremented and request2 will fail will
> > > StalePageException and just re-render with the last state (the one
> after
> > > request1). So you may see more "do-nothing" interactions with the page
> > than
> > > now.
> > >
> > >
> > > >
> > > >
> > > >
> > > > On Fri, Sep 26, 2014 at 11:58 AM, Martin Grigorov <
> > mgrigorov@apache.org>
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > What you describe is what several users currently do by using
> > > > > NoVersionMapper.
> > > > > NoVersionMapper is the thing that hides the ?pageId from the url in
> > the
> > > > > address bar.
> > > > >
> > > > > The changes you suggest to be done in SinglePageManager
> (effectively
> > > > remove
> > > > > SinglePageManager completely) is the current default behavior in
> > > Wicket.
> > > > >
> > > > > The "hole" is that F5 (page refresh) loses the state and creates a
> > > > > completely new page instance with its own state. Using back/forward
> > > will
> > > > > lose the state too.
> > > > > This is the reason why NoVersionMapper is not in the official
> Wicket
> > > > > distro.
> > > > >
> > > > > Martin Grigorov
> > > > > Wicket Training and Consulting
> > > > > https://twitter.com/mtgrigorov
> > > > >
> > > > > On Fri, Sep 26, 2014 at 10:52 AM, mscoon <ms...@gmail.com> wrote:
> > > > >
> > > > > > Martin,
> > > > > >
> > > > > > I found you "single-page-instance" sample very interesting.
> > > > > >
> > > > > > I have the following question if you can spare some time:
> > > > > >
> > > > > > What happens if you completely remove the local map in
> > > > SinglePageManager
> > > > > > (and the associated) code?
> > > > > >
> > > > > > I.e. if SinglePageManager#getPage(int id) always delegates to the
> > > > > > underlying manager and SinglePageManager#newPage() always
> returns a
> > > new
> > > > > > page from the underlying factory.
> > > > > >
> > > > > > It seems that then you get the following:
> > > > > > 1. Every time you hit a page either by url or navigation, you
> get a
> > > > fresh
> > > > > > instance, but without a version parameter in the url. Effectively
> > you
> > > > > get a
> > > > > > new version of the page but the url does not include the version
> > > > number.
> > > > > > 2. Interactions with the page affect the specific version. As
> long
> > as
> > > > you
> > > > > > keep interacting with the page (e.g. "Increment"), you are fine.
> > You
> > > > can
> > > > > > even have the same page in two tabs with different state.
> > > > > > 3. If you hit F5 you go back to the page's original state
> > > > > >
> > > > > > I think the behavior outlined above is also valid for several use
> > > cases
> > > > > > (e.g. facebook's profile page works like this - there are a lot
> of
> > > ajax
> > > > > > interactions but if you hit F5 you go back to the page's original
> > > > state).
> > > > > >
> > > > > > Do you see any holes?
> > > > > >
> > > > > > Thanks
> > > > > > Marios
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: turning off page versioning

[Martin Grigorov <mg...@apache.org>]

Thanks for testing!
I'm sure there will be problems to be solved.
The app is just a proof of concept that it is not that hard to accomplish
what Garret wanted.
If someone wants to use this in production then (s)he will have to test and
optimize it further.

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Fri, Sep 26, 2014 at 12:58 PM, mscoon <ms...@gmail.com> wrote:

> I just tried your demo, it does seem to redirect (the requested url is ?0
> while the current url has no version number)...
>
> But I was referring to the use of NoVersionMapper without
> SinglePageManager. I tried this too, and redirect to render breaks because
> the redirect is to http://blahblah/a and has no way of knowing which
> version should be used.
>
> Redirect to buffer apparently works because the response was buffered
> during the initial request that did include a page version in the url.
>
> On Fri, Sep 26, 2014 at 1:34 PM, Martin Grigorov <mg...@apache.org>
> wrote:
>
> > On Fri, Sep 26, 2014 at 12:23 PM, mscoon <ms...@gmail.com> wrote:
> >
> > > Okay I see.
> > >
> > > I imagine this approach breaks if the render strategy is
> > REDIRECT_TO_RENDER
> > > and works in ONE_PASS_RENDER and REDIRECT_TO_BUFFER.
> > >
> >
> > Wicket will redirect only if the requested url differs with the response
> > url.
> > Since the ?pageId is not in the url anymore then it depends only on the
> > page parameters.
> > As you can see in the demo app I haven't played with this.
> >
> >
> > >
> > > Also REDIRECT_TO_BUFFER works sort of by chance? What would happen if
> > > somehow requests from different tabs for the same page (url) were
> handled
> > > simultaneously?
> > >
> >
> > Wicket serializes the access to page instance. Since there is only one
> page
> > instance per type then multitab support is more limited than current
> > Wicket.
> > Request1 will acquire the permit to use the page instance and request2
> will
> > wait on PageAccessSynchronizer. Once request1 finishes then if it is Ajax
> > then all as before/now. But if request1 is normal (non-Ajax) then
> > page#renderCount will be incremented and request2 will fail will
> > StalePageException and just re-render with the last state (the one after
> > request1). So you may see more "do-nothing" interactions with the page
> than
> > now.
> >
> >
> > >
> > >
> > >
> > > On Fri, Sep 26, 2014 at 11:58 AM, Martin Grigorov <
> mgrigorov@apache.org>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > What you describe is what several users currently do by using
> > > > NoVersionMapper.
> > > > NoVersionMapper is the thing that hides the ?pageId from the url in
> the
> > > > address bar.
> > > >
> > > > The changes you suggest to be done in SinglePageManager (effectively
> > > remove
> > > > SinglePageManager completely) is the current default behavior in
> > Wicket.
> > > >
> > > > The "hole" is that F5 (page refresh) loses the state and creates a
> > > > completely new page instance with its own state. Using back/forward
> > will
> > > > lose the state too.
> > > > This is the reason why NoVersionMapper is not in the official Wicket
> > > > distro.
> > > >
> > > > Martin Grigorov
> > > > Wicket Training and Consulting
> > > > https://twitter.com/mtgrigorov
> > > >
> > > > On Fri, Sep 26, 2014 at 10:52 AM, mscoon <ms...@gmail.com> wrote:
> > > >
> > > > > Martin,
> > > > >
> > > > > I found you "single-page-instance" sample very interesting.
> > > > >
> > > > > I have the following question if you can spare some time:
> > > > >
> > > > > What happens if you completely remove the local map in
> > > SinglePageManager
> > > > > (and the associated) code?
> > > > >
> > > > > I.e. if SinglePageManager#getPage(int id) always delegates to the
> > > > > underlying manager and SinglePageManager#newPage() always returns a
> > new
> > > > > page from the underlying factory.
> > > > >
> > > > > It seems that then you get the following:
> > > > > 1. Every time you hit a page either by url or navigation, you get a
> > > fresh
> > > > > instance, but without a version parameter in the url. Effectively
> you
> > > > get a
> > > > > new version of the page but the url does not include the version
> > > number.
> > > > > 2. Interactions with the page affect the specific version. As long
> as
> > > you
> > > > > keep interacting with the page (e.g. "Increment"), you are fine.
> You
> > > can
> > > > > even have the same page in two tabs with different state.
> > > > > 3. If you hit F5 you go back to the page's original state
> > > > >
> > > > > I think the behavior outlined above is also valid for several use
> > cases
> > > > > (e.g. facebook's profile page works like this - there are a lot of
> > ajax
> > > > > interactions but if you hit F5 you go back to the page's original
> > > state).
> > > > >
> > > > > Do you see any holes?
> > > > >
> > > > > Thanks
> > > > > Marios
> > > > >
> > > >
> > >
> >
>

Re: turning off page versioning

[mscoon <ms...@gmail.com>]

I just tried your demo, it does seem to redirect (the requested url is ?0
while the current url has no version number)...

But I was referring to the use of NoVersionMapper without
SinglePageManager. I tried this too, and redirect to render breaks because
the redirect is to http://blahblah/a and has no way of knowing which
version should be used.

Redirect to buffer apparently works because the response was buffered
during the initial request that did include a page version in the url.

On Fri, Sep 26, 2014 at 1:34 PM, Martin Grigorov <mg...@apache.org>
wrote:

> On Fri, Sep 26, 2014 at 12:23 PM, mscoon <ms...@gmail.com> wrote:
>
> > Okay I see.
> >
> > I imagine this approach breaks if the render strategy is
> REDIRECT_TO_RENDER
> > and works in ONE_PASS_RENDER and REDIRECT_TO_BUFFER.
> >
>
> Wicket will redirect only if the requested url differs with the response
> url.
> Since the ?pageId is not in the url anymore then it depends only on the
> page parameters.
> As you can see in the demo app I haven't played with this.
>
>
> >
> > Also REDIRECT_TO_BUFFER works sort of by chance? What would happen if
> > somehow requests from different tabs for the same page (url) were handled
> > simultaneously?
> >
>
> Wicket serializes the access to page instance. Since there is only one page
> instance per type then multitab support is more limited than current
> Wicket.
> Request1 will acquire the permit to use the page instance and request2 will
> wait on PageAccessSynchronizer. Once request1 finishes then if it is Ajax
> then all as before/now. But if request1 is normal (non-Ajax) then
> page#renderCount will be incremented and request2 will fail will
> StalePageException and just re-render with the last state (the one after
> request1). So you may see more "do-nothing" interactions with the page than
> now.
>
>
> >
> >
> >
> > On Fri, Sep 26, 2014 at 11:58 AM, Martin Grigorov <mg...@apache.org>
> > wrote:
> >
> > > Hi,
> > >
> > > What you describe is what several users currently do by using
> > > NoVersionMapper.
> > > NoVersionMapper is the thing that hides the ?pageId from the url in the
> > > address bar.
> > >
> > > The changes you suggest to be done in SinglePageManager (effectively
> > remove
> > > SinglePageManager completely) is the current default behavior in
> Wicket.
> > >
> > > The "hole" is that F5 (page refresh) loses the state and creates a
> > > completely new page instance with its own state. Using back/forward
> will
> > > lose the state too.
> > > This is the reason why NoVersionMapper is not in the official Wicket
> > > distro.
> > >
> > > Martin Grigorov
> > > Wicket Training and Consulting
> > > https://twitter.com/mtgrigorov
> > >
> > > On Fri, Sep 26, 2014 at 10:52 AM, mscoon <ms...@gmail.com> wrote:
> > >
> > > > Martin,
> > > >
> > > > I found you "single-page-instance" sample very interesting.
> > > >
> > > > I have the following question if you can spare some time:
> > > >
> > > > What happens if you completely remove the local map in
> > SinglePageManager
> > > > (and the associated) code?
> > > >
> > > > I.e. if SinglePageManager#getPage(int id) always delegates to the
> > > > underlying manager and SinglePageManager#newPage() always returns a
> new
> > > > page from the underlying factory.
> > > >
> > > > It seems that then you get the following:
> > > > 1. Every time you hit a page either by url or navigation, you get a
> > fresh
> > > > instance, but without a version parameter in the url. Effectively you
> > > get a
> > > > new version of the page but the url does not include the version
> > number.
> > > > 2. Interactions with the page affect the specific version. As long as
> > you
> > > > keep interacting with the page (e.g. "Increment"), you are fine. You
> > can
> > > > even have the same page in two tabs with different state.
> > > > 3. If you hit F5 you go back to the page's original state
> > > >
> > > > I think the behavior outlined above is also valid for several use
> cases
> > > > (e.g. facebook's profile page works like this - there are a lot of
> ajax
> > > > interactions but if you hit F5 you go back to the page's original
> > state).
> > > >
> > > > Do you see any holes?
> > > >
> > > > Thanks
> > > > Marios
> > > >
> > >
> >
>

Re: turning off page versioning

[Martin Grigorov <mg...@apache.org>]

On Fri, Sep 26, 2014 at 12:23 PM, mscoon <ms...@gmail.com> wrote:

> Okay I see.
>
> I imagine this approach breaks if the render strategy is REDIRECT_TO_RENDER
> and works in ONE_PASS_RENDER and REDIRECT_TO_BUFFER.
>

Wicket will redirect only if the requested url differs with the response
url.
Since the ?pageId is not in the url anymore then it depends only on the
page parameters.
As you can see in the demo app I haven't played with this.


>
> Also REDIRECT_TO_BUFFER works sort of by chance? What would happen if
> somehow requests from different tabs for the same page (url) were handled
> simultaneously?
>

Wicket serializes the access to page instance. Since there is only one page
instance per type then multitab support is more limited than current Wicket.
Request1 will acquire the permit to use the page instance and request2 will
wait on PageAccessSynchronizer. Once request1 finishes then if it is Ajax
then all as before/now. But if request1 is normal (non-Ajax) then
page#renderCount will be incremented and request2 will fail will
StalePageException and just re-render with the last state (the one after
request1). So you may see more "do-nothing" interactions with the page than
now.


>
>
>
> On Fri, Sep 26, 2014 at 11:58 AM, Martin Grigorov <mg...@apache.org>
> wrote:
>
> > Hi,
> >
> > What you describe is what several users currently do by using
> > NoVersionMapper.
> > NoVersionMapper is the thing that hides the ?pageId from the url in the
> > address bar.
> >
> > The changes you suggest to be done in SinglePageManager (effectively
> remove
> > SinglePageManager completely) is the current default behavior in Wicket.
> >
> > The "hole" is that F5 (page refresh) loses the state and creates a
> > completely new page instance with its own state. Using back/forward will
> > lose the state too.
> > This is the reason why NoVersionMapper is not in the official Wicket
> > distro.
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
> >
> > On Fri, Sep 26, 2014 at 10:52 AM, mscoon <ms...@gmail.com> wrote:
> >
> > > Martin,
> > >
> > > I found you "single-page-instance" sample very interesting.
> > >
> > > I have the following question if you can spare some time:
> > >
> > > What happens if you completely remove the local map in
> SinglePageManager
> > > (and the associated) code?
> > >
> > > I.e. if SinglePageManager#getPage(int id) always delegates to the
> > > underlying manager and SinglePageManager#newPage() always returns a new
> > > page from the underlying factory.
> > >
> > > It seems that then you get the following:
> > > 1. Every time you hit a page either by url or navigation, you get a
> fresh
> > > instance, but without a version parameter in the url. Effectively you
> > get a
> > > new version of the page but the url does not include the version
> number.
> > > 2. Interactions with the page affect the specific version. As long as
> you
> > > keep interacting with the page (e.g. "Increment"), you are fine. You
> can
> > > even have the same page in two tabs with different state.
> > > 3. If you hit F5 you go back to the page's original state
> > >
> > > I think the behavior outlined above is also valid for several use cases
> > > (e.g. facebook's profile page works like this - there are a lot of ajax
> > > interactions but if you hit F5 you go back to the page's original
> state).
> > >
> > > Do you see any holes?
> > >
> > > Thanks
> > > Marios
> > >
> >
>

Re: turning off page versioning

[mscoon <ms...@gmail.com>]

Okay I see.

I imagine this approach breaks if the render strategy is REDIRECT_TO_RENDER
and works in ONE_PASS_RENDER and REDIRECT_TO_BUFFER.

Also REDIRECT_TO_BUFFER works sort of by chance? What would happen if
somehow requests from different tabs for the same page (url) were handled
simultaneously?



On Fri, Sep 26, 2014 at 11:58 AM, Martin Grigorov <mg...@apache.org>
wrote:

> Hi,
>
> What you describe is what several users currently do by using
> NoVersionMapper.
> NoVersionMapper is the thing that hides the ?pageId from the url in the
> address bar.
>
> The changes you suggest to be done in SinglePageManager (effectively remove
> SinglePageManager completely) is the current default behavior in Wicket.
>
> The "hole" is that F5 (page refresh) loses the state and creates a
> completely new page instance with its own state. Using back/forward will
> lose the state too.
> This is the reason why NoVersionMapper is not in the official Wicket
> distro.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Fri, Sep 26, 2014 at 10:52 AM, mscoon <ms...@gmail.com> wrote:
>
> > Martin,
> >
> > I found you "single-page-instance" sample very interesting.
> >
> > I have the following question if you can spare some time:
> >
> > What happens if you completely remove the local map in SinglePageManager
> > (and the associated) code?
> >
> > I.e. if SinglePageManager#getPage(int id) always delegates to the
> > underlying manager and SinglePageManager#newPage() always returns a new
> > page from the underlying factory.
> >
> > It seems that then you get the following:
> > 1. Every time you hit a page either by url or navigation, you get a fresh
> > instance, but without a version parameter in the url. Effectively you
> get a
> > new version of the page but the url does not include the version number.
> > 2. Interactions with the page affect the specific version. As long as you
> > keep interacting with the page (e.g. "Increment"), you are fine. You can
> > even have the same page in two tabs with different state.
> > 3. If you hit F5 you go back to the page's original state
> >
> > I think the behavior outlined above is also valid for several use cases
> > (e.g. facebook's profile page works like this - there are a lot of ajax
> > interactions but if you hit F5 you go back to the page's original state).
> >
> > Do you see any holes?
> >
> > Thanks
> > Marios
> >
>

Re: turning off page versioning

[Martin Grigorov <mg...@apache.org>]

Hi,

What you describe is what several users currently do by using
NoVersionMapper.
NoVersionMapper is the thing that hides the ?pageId from the url in the
address bar.

The changes you suggest to be done in SinglePageManager (effectively remove
SinglePageManager completely) is the current default behavior in Wicket.

The "hole" is that F5 (page refresh) loses the state and creates a
completely new page instance with its own state. Using back/forward will
lose the state too.
This is the reason why NoVersionMapper is not in the official Wicket distro.

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Fri, Sep 26, 2014 at 10:52 AM, mscoon <ms...@gmail.com> wrote:

> Martin,
>
> I found you "single-page-instance" sample very interesting.
>
> I have the following question if you can spare some time:
>
> What happens if you completely remove the local map in SinglePageManager
> (and the associated) code?
>
> I.e. if SinglePageManager#getPage(int id) always delegates to the
> underlying manager and SinglePageManager#newPage() always returns a new
> page from the underlying factory.
>
> It seems that then you get the following:
> 1. Every time you hit a page either by url or navigation, you get a fresh
> instance, but without a version parameter in the url. Effectively you get a
> new version of the page but the url does not include the version number.
> 2. Interactions with the page affect the specific version. As long as you
> keep interacting with the page (e.g. "Increment"), you are fine. You can
> even have the same page in two tabs with different state.
> 3. If you hit F5 you go back to the page's original state
>
> I think the behavior outlined above is also valid for several use cases
> (e.g. facebook's profile page works like this - there are a lot of ajax
> interactions but if you hit F5 you go back to the page's original state).
>
> Do you see any holes?
>
> Thanks
> Marios
>

Re: turning off page versioning

[mscoon <ms...@gmail.com>]

Martin,

I found you "single-page-instance" sample very interesting.

I have the following question if you can spare some time:

What happens if you completely remove the local map in SinglePageManager
(and the associated) code?

I.e. if SinglePageManager#getPage(int id) always delegates to the
underlying manager and SinglePageManager#newPage() always returns a new
page from the underlying factory.

It seems that then you get the following:
1. Every time you hit a page either by url or navigation, you get a fresh
instance, but without a version parameter in the url. Effectively you get a
new version of the page but the url does not include the version number.
2. Interactions with the page affect the specific version. As long as you
keep interacting with the page (e.g. "Increment"), you are fine. You can
even have the same page in two tabs with different state.
3. If you hit F5 you go back to the page's original state

I think the behavior outlined above is also valid for several use cases
(e.g. facebook's profile page works like this - there are a lot of ajax
interactions but if you hit F5 you go back to the page's original state).

Do you see any holes?

Thanks
Marios

Re: turning off page versioning

[Martin Grigorov <mg...@apache.org>]

Garret,

Please take a look at https://github.com/martin-g/single-page-instance
- single page instance per class
- stateful
- no ?pageId in the url

I hope when your next application is bought by
Facebook/Microsoft/Amazon/... you say a good word about Apache Wicket ;-)


Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Thu, Sep 25, 2014 at 2:35 AM, Jesse Long <jp...@unknown.za.net> wrote:

> On 24/09/2014 16:22, Garret Wilson wrote:
>
>> On 9/24/2014 9:26 AM, Martijn Dashorst wrote:
>>
>>> On Wed, Sep 24, 2014 at 2:13 AM, Garret Wilson <ga...@globalmentor.com>
>>> wrote:
>>>
>>>> I'm not denying that versioned pages may be a useful concept for some
>>>> use
>>>> cases (even though I can't think of any offhand).
>>>>
>>> Persioning is a very useful concept and used in many applications. You
>>> are just focussing on your particular use case for today and not
>>> thinking of broader issues that we have tackled for about a decade.
>>>
>>> Take google's search page with the pagination at the bottom. Click on
>>> 2, click on back. What do you expect? go back to the page before you
>>> searched google? Or go back to page 1?
>>>
>>>
>>>
>> But note that in your example you're not talking about the "version of
>> the page". You're pointing to a /navigation control/, which of course I
>> would expect to interact with navigation. Notice that when you page back
>> and forth, you actually change the URL query (e.g. start=10). So you're not
>> changing the "version" of the page---you're actually modifying the query
>> you send to the page, and of course you can navigate among different page
>> queries. In fact Wicket already has a totally separate mechanism for
>> sending queries to pages through page parameters, exactly like Google is
>> doing.
>>
>> I am completely in favor of sending page query parameters in the URL when
>> I want to specify what data should be retrieved from a query, and for the
>> user to navigate among queries. But I still (in my use case) don't have a
>> need for that same query page to be "versioned".
>>
>
> Hi Garret,
>
> (Side note: you probably should not be overriding isVisible(). Call
> setVisibilityAllowed() in onConfigure(). isVisible() is often called
> multiple times during a request cycle and, if expensive, can lead to some
> slowness.)
>
> Page classes are mounted at a specific URL, not page instances. A page
> instance is made up of a component tree as well as page state - data stored
> in the component tree. When you request a mounted URL, you get a new page
> instance as created from that mounted page class. That is the basic
> contract of the mount. Serving up anything other than this would be
> incorrect, as it breaks the contract.
>
> Humor me here. Please think of the page instance strictly as component
> tree and page state. Think of the page class as a starting point, a
> factory. If you create a new object from the class, you get a specific page
> instance (again, think component tree and page state).
>
> Now, if the page state or component tree changes, the page instance is no
> longer "that thing you would get if you created a new instance of that page
> class". It is a different beast now. The fact that this  Wicket has no
> business serving up this beast when the user requested the mounted URL, aka
> "that thing you would get if you created a new instance of that page class".
>
> Every time the component tree or page state changes, it is no longer the
> same page. Because it is no longer the same page, the URL changes. This is
> where is helps to think of a page as a component tree and page state. Its
> not so much different versions of the same page, as much as different pages.
>
> I'd like to point specifically to the impact of page state here. Being
> able to record state in the page object is one of the things that makes
> Wicket awesome, but it is not the only place to store state. You can also
> store state in the session, in a database, and in cookie, query and post
> parameters.
>
> When Wicket talks about stateful pages, its talking about component tree
> and page state (the state stored in the component tree - the Page object
> being the root of the component tree). A Wicket page is stateful when it
> does, or could, change the component tree or PAGE state. When a page does
> not modify the PAGE state, then it is stateless in Wicket language (excuse
> the simplification).
>
> Using stateless pages reading and writing state outside of the page object
> can get you most, if not all, of what you want.
>
> Lets take your Facebook example:
>
> 1. "Each time you go to https://www.facebook.com/jdoe, it would
>    redirect you to https://www.facebook.com/jdoe?1". Not if it was a
>    stateless page.
> 2. "Imagine if you clicked "Like" on somebody's picture, and it
>    redirectred you to https://www.facebook.com/jdoe?3". Again, not if
>    it was a stateless page. Why should clicking "Like" change the page
>    state or the component tree? In other words, why does this need to
>    be a stateful link, why not use a StatelessLink? All the data of who
>    likes what is not stored in PAGE state. It is stored in a database.
> 3. "But it still kept https://www.facebook.com/jdoe?2 in memory, so
>    that when you hit "Back" you'd see the picture before you liked
>    it.". Again, stateless pages are not stored in the page store, so
>    you would have a /jdoe?2 in memory. Also, whether or not you like a
>    picture should not be pulled from page state, but from a database or
>    cache somewhere. The page runs onConfigure each time before
>    rendering, so you would highlight the little thumbs up on the next
>    render if the value in the database now indicates that the picture
>    is liked.
> 4. "So you're saying that if I'm careful to use all dynamic models
>    (even overriding isVisible() for components to dynamically query
>    whether they should be visible), then my web application will wind
>    up with many versions of the same page serialized on disk somewhere,
>    all with different URL queries, and the user can navigate among
>    them, but when rendered they will all show 100% the same data?" With
>    a stateless page, you would have no copies serialized. A new page
>    would be created each time. No navigating between different copies.
>    Each time the URL is requested, a new instance is created to display
>    the backing data, whatever that may be at the time.
>
> To take your Google example, the state is being managed in the query
> parameters, not the page state. You dont need stateful pages here either.
> You can use stateless, bookmarkable links.
>
> Your initial use case of having a staging page which should look the same
> for all requests in that session. Would it not make sense to store the data
> in the session, use a stateless page to manipulate and display the data
> stored in the session?
>
> Cheers,
> Jesse
>
>

Re: turning off page versioning

[Jesse Long <jp...@unknown.za.net>]

On 24/09/2014 16:22, Garret Wilson wrote:
> On 9/24/2014 9:26 AM, Martijn Dashorst wrote:
>> On Wed, Sep 24, 2014 at 2:13 AM, Garret Wilson 
>> <ga...@globalmentor.com> wrote:
>>> I'm not denying that versioned pages may be a useful concept for 
>>> some use
>>> cases (even though I can't think of any offhand).
>> Persioning is a very useful concept and used in many applications. You
>> are just focussing on your particular use case for today and not
>> thinking of broader issues that we have tackled for about a decade.
>>
>> Take google's search page with the pagination at the bottom. Click on
>> 2, click on back. What do you expect? go back to the page before you
>> searched google? Or go back to page 1?
>>
>>
>
> But note that in your example you're not talking about the "version of 
> the page". You're pointing to a /navigation control/, which of course 
> I would expect to interact with navigation. Notice that when you page 
> back and forth, you actually change the URL query (e.g. start=10). So 
> you're not changing the "version" of the page---you're actually 
> modifying the query you send to the page, and of course you can 
> navigate among different page queries. In fact Wicket already has a 
> totally separate mechanism for sending queries to pages through page 
> parameters, exactly like Google is doing.
>
> I am completely in favor of sending page query parameters in the URL 
> when I want to specify what data should be retrieved from a query, and 
> for the user to navigate among queries. But I still (in my use case) 
> don't have a need for that same query page to be "versioned".

Hi Garret,

(Side note: you probably should not be overriding isVisible(). Call 
setVisibilityAllowed() in onConfigure(). isVisible() is often called 
multiple times during a request cycle and, if expensive, can lead to 
some slowness.)

Page classes are mounted at a specific URL, not page instances. A page 
instance is made up of a component tree as well as page state - data 
stored in the component tree. When you request a mounted URL, you get a 
new page instance as created from that mounted page class. That is the 
basic contract of the mount. Serving up anything other than this would 
be incorrect, as it breaks the contract.

Humor me here. Please think of the page instance strictly as component 
tree and page state. Think of the page class as a starting point, a 
factory. If you create a new object from the class, you get a specific 
page instance (again, think component tree and page state).

Now, if the page state or component tree changes, the page instance is 
no longer "that thing you would get if you created a new instance of 
that page class". It is a different beast now. The fact that this  
Wicket has no business serving up this beast when the user requested the 
mounted URL, aka "that thing you would get if you created a new instance 
of that page class".

Every time the component tree or page state changes, it is no longer the 
same page. Because it is no longer the same page, the URL changes. This 
is where is helps to think of a page as a component tree and page state. 
Its not so much different versions of the same page, as much as 
different pages.

I'd like to point specifically to the impact of page state here. Being 
able to record state in the page object is one of the things that makes 
Wicket awesome, but it is not the only place to store state. You can 
also store state in the session, in a database, and in cookie, query and 
post parameters.

When Wicket talks about stateful pages, its talking about component tree 
and page state (the state stored in the component tree - the Page object 
being the root of the component tree). A Wicket page is stateful when it 
does, or could, change the component tree or PAGE state. When a page 
does not modify the PAGE state, then it is stateless in Wicket language 
(excuse the simplification).

Using stateless pages reading and writing state outside of the page 
object can get you most, if not all, of what you want.

Lets take your Facebook example:

 1. "Each time you go to https://www.facebook.com/jdoe, it would
    redirect you to https://www.facebook.com/jdoe?1". Not if it was a
    stateless page.
 2. "Imagine if you clicked "Like" on somebody's picture, and it
    redirectred you to https://www.facebook.com/jdoe?3". Again, not if
    it was a stateless page. Why should clicking "Like" change the page
    state or the component tree? In other words, why does this need to
    be a stateful link, why not use a StatelessLink? All the data of who
    likes what is not stored in PAGE state. It is stored in a database.
 3. "But it still kept https://www.facebook.com/jdoe?2 in memory, so
    that when you hit "Back" you'd see the picture before you liked
    it.". Again, stateless pages are not stored in the page store, so
    you would have a /jdoe?2 in memory. Also, whether or not you like a
    picture should not be pulled from page state, but from a database or
    cache somewhere. The page runs onConfigure each time before
    rendering, so you would highlight the little thumbs up on the next
    render if the value in the database now indicates that the picture
    is liked.
 4. "So you're saying that if I'm careful to use all dynamic models
    (even overriding isVisible() for components to dynamically query
    whether they should be visible), then my web application will wind
    up with many versions of the same page serialized on disk somewhere,
    all with different URL queries, and the user can navigate among
    them, but when rendered they will all show 100% the same data?" With
    a stateless page, you would have no copies serialized. A new page
    would be created each time. No navigating between different copies.
    Each time the URL is requested, a new instance is created to display
    the backing data, whatever that may be at the time.

To take your Google example, the state is being managed in the query 
parameters, not the page state. You dont need stateful pages here 
either. You can use stateless, bookmarkable links.

Your initial use case of having a staging page which should look the 
same for all requests in that session. Would it not make sense to store 
the data in the session, use a stateless page to manipulate and display 
the data stored in the session?

Cheers,
Jesse

Re: turning off page versioning

[Garret Wilson <ga...@globalmentor.com>]

On 9/24/2014 9:26 AM, Martijn Dashorst wrote:
> On Wed, Sep 24, 2014 at 2:13 AM, Garret Wilson <ga...@globalmentor.com> wrote:
>> I'm not denying that versioned pages may be a useful concept for some use
>> cases (even though I can't think of any offhand).
> Persioning is a very useful concept and used in many applications. You
> are just focussing on your particular use case for today and not
> thinking of broader issues that we have tackled for about a decade.
>
> Take google's search page with the pagination at the bottom. Click on
> 2, click on back. What do you expect? go back to the page before you
> searched google? Or go back to page 1?
>
>

But note that in your example you're not talking about the "version of 
the page". You're pointing to a /navigation control/, which of course I 
would expect to interact with navigation. Notice that when you page back 
and forth, you actually change the URL query (e.g. start=10). So you're 
not changing the "version" of the page---you're actually modifying the 
query you send to the page, and of course you can navigate among 
different page queries. In fact Wicket already has a totally separate 
mechanism for sending queries to pages through page parameters, exactly 
like Google is doing.

I am completely in favor of sending page query parameters in the URL 
when I want to specify what data should be retrieved from a query, and 
for the user to navigate among queries. But I still (in my use case) 
don't have a need for that same query page to be "versioned".

Garret

Re: turning off page versioning

[Thibault Kruse <ti...@googlemail.com>]

You could generally tune down on telling the world about your
emotional state on technical mailing lists, your emotional state is of
no significant interest to the people who registered to this mailing
list, at least no in the amount you provide. We got it the first time.

And e.g. your phrasing "Yeah, I definitely want to turn that off."
seems to imply that you'd be stupid not to turn that off, which seems
to imply anyone who does not turn it off is stupid. This is just one
example.

Your usage of exclamation marks, exaggerations and repetitions can
also be perceived as condescending, because it implies the audience is
unable to see the truth as you do, unless you shout or emphasize it
for the audience.

So avoiding sarcasm and needless emphasis can help prevent
misunderstandings, and helps everybody to focus on the technical issue
at hand.



On Wed, Sep 24, 2014 at 4:49 PM, Garret Wilson <ga...@globalmentor.com> wrote:
> On 9/24/2014 11:18 AM, Martijn Dashorst wrote:
>>
>> ...
>> And ranting about how stupid we are for having page versions doesn't
>> help either.
>
>
> Hey, wait a minute. Where did that come from? That sort of hurts my
> feelings. I brought up this topic, and I've said throughout this discussion
> that versioning may have its use cases, but it's just not what I need at the
> moment, and I simply asked for a way to turn it off.
>
> That was sort of a "cheap shot" as we say, Martijn. I never said anyone was
> stupid. I asked a simple, honest developer question about how to turn off a
> feature. I was very disappointed to learn that it couldn't be turned off.
> But I tried to make clear I wasn't angry at anyone specifically nor was I
> questioning anybody's competence.
>
> I think that comment was totally unfair.
>
> Garret
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: turning off page versioning

[Garret Wilson <ga...@globalmentor.com>]

On 9/24/2014 11:18 AM, Martijn Dashorst wrote:
> ...
> And ranting about how stupid we are for having page versions doesn't
> help either.

Hey, wait a minute. Where did that come from? That sort of hurts my 
feelings. I brought up this topic, and I've said throughout this 
discussion that versioning may have its use cases, but it's just not 
what I need at the moment, and I simply asked for a way to turn it off.

That was sort of a "cheap shot" as we say, Martijn. I never said anyone 
was stupid. I asked a simple, honest developer question about how to 
turn off a feature. I was very disappointed to learn that it couldn't be 
turned off. But I tried to make clear I wasn't angry at anyone 
specifically nor was I questioning anybody's competence.

I think that comment was totally unfair.

Garret

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: turning off page versioning

[Martijn Dashorst <ma...@gmail.com>]

There's probably a particular way of how we (at my €day job) develop
applications, but of all the problems our users report back to us,
none of them involve confusion about the back button behaviour. Either
our users don't know the back button exists, or they have become
accustomed to not using it in other applications and therefore don't
use it in ours or the way we develop our applications makes the back
button behave according to our users' expectations.

Many of our filter form controls update using Ajax, which doesn't
trigger a version update, so navigating back will take you back to the
previous page.

I've said it before in a different discussion about the few bug
reports that come from our company while we have ~2-3 million lines of
code related to Wicket: we shaped Wicket over the years and Wicket
shaped us–for better and for worse. We have moulded Wicket while
crafting those 3M lines. As Wicket developed, it shaped our
development process as well, allowing us to navigate around those
hidden potholes without us even knowing them.

But what Wicket isn't and hasn't been is a stateless HTML templating
engine. It's reason d'être is developing stateful web applications. It
was designed to do that specifically. We set out to solve the problem
of back button presses and maintaining state between those pages, of
having a web application open in multiple tabs and solving maintaining
state between the multiple tabs, of managing state of complex
component hierarchies where you have sorting and paging of multiple
lists on one page.

That is to say: this is what Wicket currently is. A future Wicket
evolves and might have the state management be less ingrained in its
core, but given the 10 year history this is not a simple feat to pull
off.

And ranting about how stupid we are for having page versions doesn't
help either.

Martijn



On Wed, Sep 24, 2014 at 3:30 PM, Nick Pratt <nb...@gmail.com> wrote:
> Funny this thread appeared this week - I had a client question our
> forward/back navigation last Wednesday and we got into a fairly lengthy
> discussion about this specific topic.  What came out of that was that their
> expectations of page navigation in a webapp vs a desktop app are different
> in today's fairly accessible web world where all their users have access
> to, and use a variety of web apps on a daily basis (as examples given -
> Gmail, Outlook, Facebook, Strava, FreshDirect, Google Search, NYTimes, WSJ,
> Bloomberg, Amazon and various niche commercial/internal sites).  In a web
> browser, they expect that forward/back navigation changes pages (not
> versions).  In some cases, having some form data saved between page navs
> was "nice", but our forms just aren't that big that they wouldn't be upset
> about re-entering that data, had they navigated away.  In short, they felt
> the current provided functionality of state storage between page views
> (from the end user standpoint) was unnecessary (and possibly a little
> confusing in some cases) given their user's expectations of current web
> apps.
>
> I'm not intending to say either way is better/worse or right/wrong - just
> throwing another data point into the discussion.
>
> In my view, some way to disable versioning and move to a simpler model
> restful type architecture (and Im well aware we could just move to a pure
> JS+REST model and drop Wicket) would be nice.  Having used Wicket almost
> daily for 6 years I've got fairly used to it, but I do see Garret's point,
> and I have also wondered but dont know (I dont know enough about the
> internals to make a more definitive statement here) if there's a lot of
> current complexity to handle the versioning.  Were that to be removed (and
> I'm not saying or implying that it should or should not) Id be curious to
> see if there were alternative mechanisms that Wicket could employ to
> provide the current model/view simplicity that it currently does.  Maybe we
> add a mode which drops the versioning concept and simply resets all form
> elements back to their defaults when rendered. I dont know how that would
> impact data flow between the browser and Wicket.  I do also think that
> developer knowledge on webapp construction/architecture has
> changed/improved a lot in the last 6 years, and perhaps we've all learnt
> something about simpler constructs.  Perhaps not :-)
>
> JM2C.
>
> Nick
>
> On Wed, Sep 24, 2014 at 8:26 AM, Martijn Dashorst <
> martijn.dashorst@gmail.com> wrote:
>
>> On Wed, Sep 24, 2014 at 2:13 AM, Garret Wilson <ga...@globalmentor.com>
>> wrote:
>> > I'm not denying that versioned pages may be a useful concept for some use
>> > cases (even though I can't think of any offhand).
>>
>> Persioning is a very useful concept and used in many applications. You
>> are just focussing on your particular use case for today and not
>> thinking of broader issues that we have tackled for about a decade.
>>
>> Take google's search page with the pagination at the bottom. Click on
>> 2, click on back. What do you expect? go back to the page before you
>> searched google? Or go back to page 1?
>>
>> Could stateless support in Wicket be improved, sure as hell. Is there
>> a drive from the core developers to do so? Apparently our applications
>> that drive Wicket development are dependent on stateful pages and we
>> don't get caught up in a minor thing as a number showing up in a url
>> that opens up a ton of support in Wicket for complex interactions with
>> pages that were not possible before.
>>
>> Martijn
>>
>> --
>> Become a Wicket expert, learn from the best: http://wicketinaction.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: turning off page versioning

[Martin Grigorov <mg...@apache.org>]

On Wed, Sep 24, 2014 at 3:30 PM, Nick Pratt <nb...@gmail.com> wrote:

> Funny this thread appeared this week - I had a client question our
> forward/back navigation last Wednesday and we got into a fairly lengthy
> discussion about this specific topic.  What came out of that was that their
> expectations of page navigation in a webapp vs a desktop app are different
> in today's fairly accessible web world where all their users have access
> to, and use a variety of web apps on a daily basis (as examples given -
> Gmail, Outlook, Facebook, Strava, FreshDirect, Google Search, NYTimes, WSJ,
> Bloomberg, Amazon and various niche commercial/internal sites).  In a web
> browser, they expect that forward/back navigation changes pages (not
> versions).  In some cases, having some form data saved between page navs
> was "nice", but our forms just aren't that big that they wouldn't be upset
> about re-entering that data, had they navigated away.  In short, they felt
> the current provided functionality of state storage between page views
> (from the end user standpoint) was unnecessary (and possibly a little
> confusing in some cases) given their user's expectations of current web
> apps.
>
> I'm not intending to say either way is better/worse or right/wrong - just
> throwing another data point into the discussion.
>
> In my view, some way to disable versioning and move to a simpler model
> restful type architecture (and Im well aware we could just move to a pure
> JS+REST model and drop Wicket) would be nice.  Having used Wicket almost
> daily for 6 years I've got fairly used to it, but I do see Garret's point,
> and I have also wondered but dont know (I dont know enough about the
> internals to make a more definitive statement here) if there's a lot of
> current complexity to handle the versioning.  Were that to be removed (and
> I'm not saying or implying that it should or should not) Id be curious to
> see if there were alternative mechanisms that Wicket could employ to
> provide the current model/view simplicity that it currently does.  Maybe we
> add a mode which drops the versioning concept and simply resets all form
> elements back to their defaults when rendered. I dont know how that would
> impact data flow between the browser and Wicket.  I do also think that
> developer knowledge on webapp construction/architecture has
> changed/improved a lot in the last 6 years, and perhaps we've all learnt
> something about simpler constructs.  Perhaps not :-)
>

Yes, you didn't ;-)
What you just described is easily solvable by
PageSettings#setVersionPagesByDefault(false).
This single setting will tell Wicket to not create new versions of a page
*instance* when you interact with(in) it.
So pressing back/forward will go to the previous/next page, not
previous/next version of the current page instance.

There are benefits and drawbacks in stateful vs. stateless approaches. No
doubt in that!
Even with PageSettings#setVersionPagesByDefault(false) a page will be still
stateful if it uses a stateful component or behavior. The single version of
the page instance will be still stored.

Here is how I understand Garret's use case:
he wants a page (or mount path) to have a single instance per session!
Imagine a use case:
- user navigates from / to /a (1), then to /b and then again to /a (2)
- the page responsible for /a initially renders PanelA
- if the user replace PanelA with Panel2 while being at /a (2) then using
back button will lead her to /b, using again back button will lead her to
/a (1) with PanelB.

With current Wicket this is not possible because /a (1) and /a (2) are two
different page instances with their own (even single) state.
The knowledge about the instance is encoded in ?pageId.
If ?pageId is suppressed (anyhow) then current Wicket will create
completely new instance of the page responsible for /a, with its PanelA
inside.

Garret's use case is not hard to implement. As I said all that is needed is
a wrapper impl of IPageManager that translates Class<Page> to a stable int.



> JM2C.
>
> Nick
>
> On Wed, Sep 24, 2014 at 8:26 AM, Martijn Dashorst <
> martijn.dashorst@gmail.com> wrote:
>
> > On Wed, Sep 24, 2014 at 2:13 AM, Garret Wilson <ga...@globalmentor.com>
> > wrote:
> > > I'm not denying that versioned pages may be a useful concept for some
> use
> > > cases (even though I can't think of any offhand).
> >
> > Persioning is a very useful concept and used in many applications. You
> > are just focussing on your particular use case for today and not
> > thinking of broader issues that we have tackled for about a decade.
> >
> > Take google's search page with the pagination at the bottom. Click on
> > 2, click on back. What do you expect? go back to the page before you
> > searched google? Or go back to page 1?
> >
> > Could stateless support in Wicket be improved, sure as hell. Is there
> > a drive from the core developers to do so? Apparently our applications
> > that drive Wicket development are dependent on stateful pages and we
> > don't get caught up in a minor thing as a number showing up in a url
> > that opens up a ton of support in Wicket for complex interactions with
> > pages that were not possible before.
> >
> > Martijn
> >
> > --
> > Become a Wicket expert, learn from the best: http://wicketinaction.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>

Re: turning off page versioning

[Nick Pratt <nb...@gmail.com>]

Funny this thread appeared this week - I had a client question our
forward/back navigation last Wednesday and we got into a fairly lengthy
discussion about this specific topic.  What came out of that was that their
expectations of page navigation in a webapp vs a desktop app are different
in today's fairly accessible web world where all their users have access
to, and use a variety of web apps on a daily basis (as examples given -
Gmail, Outlook, Facebook, Strava, FreshDirect, Google Search, NYTimes, WSJ,
Bloomberg, Amazon and various niche commercial/internal sites).  In a web
browser, they expect that forward/back navigation changes pages (not
versions).  In some cases, having some form data saved between page navs
was "nice", but our forms just aren't that big that they wouldn't be upset
about re-entering that data, had they navigated away.  In short, they felt
the current provided functionality of state storage between page views
(from the end user standpoint) was unnecessary (and possibly a little
confusing in some cases) given their user's expectations of current web
apps.

I'm not intending to say either way is better/worse or right/wrong - just
throwing another data point into the discussion.

In my view, some way to disable versioning and move to a simpler model
restful type architecture (and Im well aware we could just move to a pure
JS+REST model and drop Wicket) would be nice.  Having used Wicket almost
daily for 6 years I've got fairly used to it, but I do see Garret's point,
and I have also wondered but dont know (I dont know enough about the
internals to make a more definitive statement here) if there's a lot of
current complexity to handle the versioning.  Were that to be removed (and
I'm not saying or implying that it should or should not) Id be curious to
see if there were alternative mechanisms that Wicket could employ to
provide the current model/view simplicity that it currently does.  Maybe we
add a mode which drops the versioning concept and simply resets all form
elements back to their defaults when rendered. I dont know how that would
impact data flow between the browser and Wicket.  I do also think that
developer knowledge on webapp construction/architecture has
changed/improved a lot in the last 6 years, and perhaps we've all learnt
something about simpler constructs.  Perhaps not :-)

JM2C.

Nick

On Wed, Sep 24, 2014 at 8:26 AM, Martijn Dashorst <
martijn.dashorst@gmail.com> wrote:

> On Wed, Sep 24, 2014 at 2:13 AM, Garret Wilson <ga...@globalmentor.com>
> wrote:
> > I'm not denying that versioned pages may be a useful concept for some use
> > cases (even though I can't think of any offhand).
>
> Persioning is a very useful concept and used in many applications. You
> are just focussing on your particular use case for today and not
> thinking of broader issues that we have tackled for about a decade.
>
> Take google's search page with the pagination at the bottom. Click on
> 2, click on back. What do you expect? go back to the page before you
> searched google? Or go back to page 1?
>
> Could stateless support in Wicket be improved, sure as hell. Is there
> a drive from the core developers to do so? Apparently our applications
> that drive Wicket development are dependent on stateful pages and we
> don't get caught up in a minor thing as a number showing up in a url
> that opens up a ton of support in Wicket for complex interactions with
> pages that were not possible before.
>
> Martijn
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Re: turning off page versioning

[Martijn Dashorst <ma...@gmail.com>]

On Wed, Sep 24, 2014 at 2:13 AM, Garret Wilson <ga...@globalmentor.com> wrote:
> I'm not denying that versioned pages may be a useful concept for some use
> cases (even though I can't think of any offhand).

Persioning is a very useful concept and used in many applications. You
are just focussing on your particular use case for today and not
thinking of broader issues that we have tackled for about a decade.

Take google's search page with the pagination at the bottom. Click on
2, click on back. What do you expect? go back to the page before you
searched google? Or go back to page 1?

Could stateless support in Wicket be improved, sure as hell. Is there
a drive from the core developers to do so? Apparently our applications
that drive Wicket development are dependent on stateful pages and we
don't get caught up in a minor thing as a number showing up in a url
that opens up a ton of support in Wicket for complex interactions with
pages that were not possible before.

Martijn

-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: turning off page versioning

[Garret Wilson <ga...@globalmentor.com>]

On 9/23/2014 12:08 PM, Martin Grigorov wrote:
> On Tue, Sep 23, 2014 at 4:44 PM, Garret Wilson <ga...@globalmentor.com>
> wrote:
>
>> OMG. What a sad email to wake up to. :(
>>
>> Let me let all that digest for a while. I never would have imagined a
>> situation this dire. Imagine if every time you went to Facebook, it
>> generated a new https://www.facebook.com/jdoe?124154451 version! So
>> basically Facebook could never use Wicket without rewriting the whole page
>> caching scheme. Or
>
> this particular url (https://www.facebook.com/jdoe?124154451) returns 404,
> but otherwise Facebook renders completely different content on page refresh
> (and I'm OK with that!)

Ah, I wasn't clear. I meant, imagine if Facebook was running on Wicket. 
Each time you go to https://www.facebook.com/jdoe, it would redirect you 
to https://www.facebook.com/jdoe?1. Imagine if you went there again and 
it redirected you to https://www.facebook.com/jdoe?2. Imagine if you 
clicked "Like" on somebody's picture, and it redirectred you to 
https://www.facebook.com/jdoe?3. But it still kept 
https://www.facebook.com/jdoe?2 in memory, so that when you hit "Back" 
you'd see the picture before you liked it. Soon you'd have 
https://www.facebook.com/jdoe?124154451...

> What is the actual problem ?
> The number in the url ?

Yes.

> Or that a new page instance is created ?

...and yes.

And both of those together cause even more problems, because not only 
are new page instances created, the user can navigate among them.

I'm not denying that versioned pages may be a useful concept for some 
use cases (even though I can't think of any offhand). I'm just saying 
it's not my use case, and I had assumed throughout development on our 
project that I could just turn it off by calling setVersioned(false). 
Your email this morning informed me that I had been under an incorrect 
assumption, and that made me sad.


>
> Imagine this:
> PageA initial state renders PanelA and a LinkA.
> Clicking on LinkA PanelA is replaced with PanelB.
>
> case 1) with the pageId in the url if you refresh the page then you will
> still see PanelB in the page
> case 2) without the pageId you will see PanelA, because a new page instance
> is created
>
> Now imagine that Wicket stores pages by type.

It's not necessarily by type---it's by mounted URL. Maybe you mount the 
same type at various URLs; they would all be kept track of separately. 
This is how Guise does it. (I'm not saying "Oh, Guise is better than 
everything." I'm just using it as an example reference here. It does 
some things better. It does some things worse. It functions like I'm 
describing now because that's the only thing I thought of when I wrote 
it.) Each mount point has a single version that is changed as the user 
interacts with it. Granted, this causes some problems when multiple 
browser tabs are opened with the same page; in the future I hope to 
address this, but it's not trivial. Guise started out with the 
assumption that the user would only have one tab opened for a page.

But in this example, yeah, a Wicket page "type" equates to a single URL 
mount point. I was being pedantic.


>   Once the user clicks LinkA
> how (s)he will be able to see the initial state with PanelA again ?

Why would the user expect or want to see PanelA again? Didn't (s)he just 
click on the link that said "remove panel A and add panel B?" If the 
user wants to see PanelA again, (s)he clicks on the link that says "put 
panel A back!"

Apparently Wicket thinks the browser "back" button is an "undo" button. 
But in my mind it's not---it's a "back" button that goes to the previous 
page. If you're still on the same page but you've changed that page, 
then you see the new version of the page!

Imagine that you're on Facebook, and you click on the button that says 
"unfriend Jane Doe" (that is, don't be friends anymore with Jane Doe). 
What happens when you hit the back button? Do you expect to get Jane Doe 
back as a friend?

Hahahah! Sorry, please forgive me for laughing at my own example. It's 
been a long, exhausting day---allow me a bit of humor before heading to bed.

Anyway, I hope you see my point. Like I said, maybe versioning has its 
use cases. It's just not /my/ use case, and I want to turn it off.

Best,

Garret

Re: turning off page versioning

[Martin Grigorov <mg...@apache.org>]

On Tue, Sep 23, 2014 at 4:44 PM, Garret Wilson <ga...@globalmentor.com>
wrote:

> OMG. What a sad email to wake up to. :(
>
> Let me let all that digest for a while. I never would have imagined a
> situation this dire. Imagine if every time you went to Facebook, it
> generated a new https://www.facebook.com/jdoe?124154451 version! So
> basically Facebook could never use Wicket without rewriting the whole page
> caching scheme. Or


this particular url (https://www.facebook.com/jdoe?124154451) returns 404,
but otherwise Facebook renders completely different content on page refresh
(and I'm OK with that!)


> LinkedIn. Or... actually, come to think of it, I can't even think of a
> single site that functions like Wicket, incrementing some "page version"
> counter every time you interact with the page, so that you can go back to
> other "versions". (Users don't want to go back to other versions! They may
> want to go back to other /pages/ at different URLs, but they realize that
> interacting with a single pages changes the state of that page---they don't
> expect that other "versions" are kept around somewhere.)
>

IPageSettings#setVersioned(false) disables the state management for all
pages in an application


>
> Continuing my scenario I outlined earlier, I have an HTML page called
> MenuPage, which has <wicket:link><a href="StagingPage.html">..., the target
> page of which functions as I explained below. Every time the user goes to
> the MenuPage and clicks on the link, you're saying that Wicket will
> generate a new version of StagingPage in the cache, even with
> setVersioned(false)? It will generate a new ...StagingPage.html?23423414
> URL? There is no way to turn that off... without essentially rewriting the
> whole Wicket page request and caching mechanism??
>

What is the actual problem ?
The number in the url ?
Or that a new page instance is created ?


>
> This is not good news. I'm not ranting, I'm crying.


Imagine this:
PageA initial state renders PanelA and a LinkA.
Clicking on LinkA PanelA is replaced with PanelB.

case 1) with the pageId in the url if you refresh the page then you will
still see PanelB in the page
case 2) without the pageId you will see PanelA, because a new page instance
is created

Now imagine that Wicket stores pages by type. Once the user clicks LinkA
how (s)he will be able to see the initial state with PanelA again ?



>
>
> Garret
>
>
> On 9/23/2014 8:24 AM, Martin Grigorov wrote:
>
>> Hi,
>>
>> In short, to accomplish all this you will need several custom impls of
>> Wicket interfaces.
>> 1) custom IRequestMapper that just ignores PageInfo when generating the
>> url
>> for IPageRequestHandler. Search in the archives for
>> "NoVersionRequestMapper"
>> 2) a completely new IPageManager (interface!) that works with Class<Page>
>> instead of with Integer (pageId)
>> So everytime a url is mapped to a page class you should use it to load the
>> Page instance for this class
>>
>> In details:
>> By design only stateless pages do not have the pageId in the url! If a
>> request without pageId comes then a completely new page instance is
>> created.
>> By using something like NoVersionRequestMapper (not supported officially!)
>> only the url for the browser address bar will miss the pageId (see
>> PageAndComponentInfo class), but the pageId is in all link/form urls so
>> clicking/submitting still works. But if the user refreshes the page (F5)
>> then the state is lost!
>>
>> About Page#setVersioned(boolean)
>> This tells Wicket to not increment the pageId after an interaction with
>> the
>> page. A pageId is associated with the page when it is instantiated, but
>> any
>> link click, form submit, etc. won't create a new version of the page. The
>> final result is that every interaction (i.e. state change) with the page
>> will lead to overriding the old one in the page stores.
>> Wicket's IPageStore/IDataStore use API like: put(String sessionId, int
>> pageId, byte[] serializedPage). At the end of every request cycle all
>> rendered stateful pages are stored. If the pageId doesn't change then some
>> old serializedPage would be overriden.
>>
>> For your requirements you will need an API like: put(String sessionId,
>> Class<Page> pageClass, byte[] serializedPage) and byte [] get(String
>> sessionId, Class<Page> pageClass).
>> You can create a IPageManager wrapper that maps sessionId+pageId to
>> pageClass and use that pageClass with custom IMyPageStore and IMyDataStore
>> impls. (Just an idea out of my mind.)
>>
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Tue, Sep 23, 2014 at 3:42 AM, Garret Wilson <ga...@globalmentor.com>
>> wrote:
>>
>>  Can someone explain to me exactly how page versioning works, and how to
>>> turn it off?
>>>
>>> I have a page StagingPage that contains a file uploader. This page is
>>> interesting in that when you upload some files with Button1, the page
>>> lists
>>> the files on the page and keeps them in a collection until you hit
>>> Button2,
>>> at which point the pages does Some Other Really Interesting Thing with
>>> the
>>> files. In other words, the page acts like a staging area for files,
>>> allowing you to 1) upload files and then 2) do something with them.
>>>
>>> I get this number on the end of the URLs which, from the page versioning
>>> and caching reference documentation <http://wicket.apache.org/
>>> guide/guide/versioningCaching.html>, seems to indicate the version of
>>> the
>>> page. I don't want this. I just want there to be one version of the page
>>> (even though it is stateful). The back button can go to the previous
>>> page;
>>> I don't care.
>>>
>>> So I turn off versioning in StagingPage with:
>>>
>>>     setVersioned(false);
>>>
>>>
>>> But I still get numbers at the end of the StagingPage URL. Worse, back
>>> and
>>> forward in my browser goes between apparently two versions of the page
>>> (one
>>> with the "Choose Files" button selecting files, and one without)---but
>>> the
>>> number in the URL doesn't change! Worse still, when I remove the number
>>> and
>>> reload the URL without the number, Wicket puts the number back but first
>>> increments the number! Now back and forward cycle between numbered URLs.
>>>
>>> I thought setVersioned(false) was supposed to turn all that off?
>>>
>>> In my own Guise framework, each page has a single component instance tree
>>> on the back end. Whatever you do at that URL, whenever you come back to
>>> it
>>> it will be just like you left it. Granted, there are several drawbacks
>>> such
>>> as memory consumption; Guise can learn a lot from Wicket in how the
>>> latter
>>> can serialize each page between requests, and versioning can be very
>>> useful
>>> in some situations. But here I just want a stateful page that has one
>>> single version---the current version. I don't want it to remember any
>>> previous versions. And I don't want numbers on the end of the URL. How
>>> can
>>> I turn off versioning for real?
>>>
>>> Thanks,
>>>
>>> Garret
>>>
>>>
>

Re: turning off page versioning

[mscoon <ms...@gmail.com>]

It is true that page version does seem kind of redundant or even annoying
at times. If you have a wicket app that is full ajax (remember that ajax
requests don't increment the page version), the only reason you need the
page version is so you can have the same page open in two different tabs
with different state.

If having the same page open multiple times with different state is
something not important for a particular application, then you may as well
not have a page version at all in the url...

As others have pointed out, I too think it would be nice if wicket could
support this out of the box (while at the same time making clear what the
drawbacks/limitations of this approach are).


On Tue, Sep 23, 2014 at 6:05 PM, Thibault Kruse <ti...@googlemail.com>
wrote:

> It is an interesting question whether other web frameworks (also
> outside JVM world) use any similar page versioning scheme to wicket. I
> am not aware of any.
>
> In any case I guess most projects using wicket would have to make
> design decisions based on whether the page version is acceptable in
> the URL or not. There is no simple way of reasonably "switching it
> off" once an application has been created without giving this some
> thought.
>
> I don't think every web-framework should strive to be the best choice
> for facebook or similar, different frameworks may have different
> strengths and weaknesses (performance, memory-consumption,
> learning-curve, maintenance-costs, prototyping-speed, etc.)
>
>
> On Tue, Sep 23, 2014 at 3:44 PM, Garret Wilson <ga...@globalmentor.com>
> wrote:
> > OMG. What a sad email to wake up to. :(
> >
> > Let me let all that digest for a while. I never would have imagined a
> > situation this dire. Imagine if every time you went to Facebook, it
> > generated a new https://www.facebook.com/jdoe?124154451 version! So
> > basically Facebook could never use Wicket without rewriting the whole
> page
> > caching scheme. Or LinkedIn. Or... actually, come to think of it, I can't
> > even think of a single site that functions like Wicket, incrementing some
> > "page version" counter every time you interact with the page, so that you
> > can go back to other "versions". (Users don't want to go back to other
> > versions! They may want to go back to other /pages/ at different URLs,
> but
> > they realize that interacting with a single pages changes the state of
> that
> > page---they don't expect that other "versions" are kept around
> somewhere.)
> >
> > Continuing my scenario I outlined earlier, I have an HTML page called
> > MenuPage, which has <wicket:link><a href="StagingPage.html">..., the
> target
> > page of which functions as I explained below. Every time the user goes to
> > the MenuPage and clicks on the link, you're saying that Wicket will
> generate
> > a new version of StagingPage in the cache, even with
> setVersioned(false)? It
> > will generate a new ...StagingPage.html?23423414 URL? There is no way to
> > turn that off... without essentially rewriting the whole Wicket page
> request
> > and caching mechanism??
> >
> > This is not good news. I'm not ranting, I'm crying.
> >
> > Garret
> >
> >
> > On 9/23/2014 8:24 AM, Martin Grigorov wrote:
> >>
> >> Hi,
> >>
> >> In short, to accomplish all this you will need several custom impls of
> >> Wicket interfaces.
> >> 1) custom IRequestMapper that just ignores PageInfo when generating the
> >> url
> >> for IPageRequestHandler. Search in the archives for
> >> "NoVersionRequestMapper"
> >> 2) a completely new IPageManager (interface!) that works with
> Class<Page>
> >> instead of with Integer (pageId)
> >> So everytime a url is mapped to a page class you should use it to load
> the
> >> Page instance for this class
> >>
> >> In details:
> >> By design only stateless pages do not have the pageId in the url! If a
> >> request without pageId comes then a completely new page instance is
> >> created.
> >> By using something like NoVersionRequestMapper (not supported
> officially!)
> >> only the url for the browser address bar will miss the pageId (see
> >> PageAndComponentInfo class), but the pageId is in all link/form urls so
> >> clicking/submitting still works. But if the user refreshes the page (F5)
> >> then the state is lost!
> >>
> >> About Page#setVersioned(boolean)
> >> This tells Wicket to not increment the pageId after an interaction with
> >> the
> >> page. A pageId is associated with the page when it is instantiated, but
> >> any
> >> link click, form submit, etc. won't create a new version of the page.
> The
> >> final result is that every interaction (i.e. state change) with the page
> >> will lead to overriding the old one in the page stores.
> >> Wicket's IPageStore/IDataStore use API like: put(String sessionId, int
> >> pageId, byte[] serializedPage). At the end of every request cycle all
> >> rendered stateful pages are stored. If the pageId doesn't change then
> some
> >> old serializedPage would be overriden.
> >>
> >> For your requirements you will need an API like: put(String sessionId,
> >> Class<Page> pageClass, byte[] serializedPage) and byte [] get(String
> >> sessionId, Class<Page> pageClass).
> >> You can create a IPageManager wrapper that maps sessionId+pageId to
> >> pageClass and use that pageClass with custom IMyPageStore and
> IMyDataStore
> >> impls. (Just an idea out of my mind.)
> >>
> >>
> >> Martin Grigorov
> >> Wicket Training and Consulting
> >> https://twitter.com/mtgrigorov
> >>
> >> On Tue, Sep 23, 2014 at 3:42 AM, Garret Wilson <garret@globalmentor.com
> >
> >> wrote:
> >>
> >>> Can someone explain to me exactly how page versioning works, and how to
> >>> turn it off?
> >>>
> >>> I have a page StagingPage that contains a file uploader. This page is
> >>> interesting in that when you upload some files with Button1, the page
> >>> lists
> >>> the files on the page and keeps them in a collection until you hit
> >>> Button2,
> >>> at which point the pages does Some Other Really Interesting Thing with
> >>> the
> >>> files. In other words, the page acts like a staging area for files,
> >>> allowing you to 1) upload files and then 2) do something with them.
> >>>
> >>> I get this number on the end of the URLs which, from the page
> versioning
> >>> and caching reference documentation <http://wicket.apache.org/
> >>> guide/guide/versioningCaching.html>, seems to indicate the version of
> the
> >>> page. I don't want this. I just want there to be one version of the
> page
> >>> (even though it is stateful). The back button can go to the previous
> >>> page;
> >>> I don't care.
> >>>
> >>> So I turn off versioning in StagingPage with:
> >>>
> >>>     setVersioned(false);
> >>>
> >>>
> >>> But I still get numbers at the end of the StagingPage URL. Worse, back
> >>> and
> >>> forward in my browser goes between apparently two versions of the page
> >>> (one
> >>> with the "Choose Files" button selecting files, and one without)---but
> >>> the
> >>> number in the URL doesn't change! Worse still, when I remove the number
> >>> and
> >>> reload the URL without the number, Wicket puts the number back but
> first
> >>> increments the number! Now back and forward cycle between numbered
> URLs.
> >>>
> >>> I thought setVersioned(false) was supposed to turn all that off?
> >>>
> >>> In my own Guise framework, each page has a single component instance
> tree
> >>> on the back end. Whatever you do at that URL, whenever you come back to
> >>> it
> >>> it will be just like you left it. Granted, there are several drawbacks
> >>> such
> >>> as memory consumption; Guise can learn a lot from Wicket in how the
> >>> latter
> >>> can serialize each page between requests, and versioning can be very
> >>> useful
> >>> in some situations. But here I just want a stateful page that has one
> >>> single version---the current version. I don't want it to remember any
> >>> previous versions. And I don't want numbers on the end of the URL. How
> >>> can
> >>> I turn off versioning for real?
> >>>
> >>> Thanks,
> >>>
> >>> Garret
> >>>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Re: turning off page versioning

[Thibault Kruse <ti...@googlemail.com>]

It is an interesting question whether other web frameworks (also
outside JVM world) use any similar page versioning scheme to wicket. I
am not aware of any.

In any case I guess most projects using wicket would have to make
design decisions based on whether the page version is acceptable in
the URL or not. There is no simple way of reasonably "switching it
off" once an application has been created without giving this some
thought.

I don't think every web-framework should strive to be the best choice
for facebook or similar, different frameworks may have different
strengths and weaknesses (performance, memory-consumption,
learning-curve, maintenance-costs, prototyping-speed, etc.)


On Tue, Sep 23, 2014 at 3:44 PM, Garret Wilson <ga...@globalmentor.com> wrote:
> OMG. What a sad email to wake up to. :(
>
> Let me let all that digest for a while. I never would have imagined a
> situation this dire. Imagine if every time you went to Facebook, it
> generated a new https://www.facebook.com/jdoe?124154451 version! So
> basically Facebook could never use Wicket without rewriting the whole page
> caching scheme. Or LinkedIn. Or... actually, come to think of it, I can't
> even think of a single site that functions like Wicket, incrementing some
> "page version" counter every time you interact with the page, so that you
> can go back to other "versions". (Users don't want to go back to other
> versions! They may want to go back to other /pages/ at different URLs, but
> they realize that interacting with a single pages changes the state of that
> page---they don't expect that other "versions" are kept around somewhere.)
>
> Continuing my scenario I outlined earlier, I have an HTML page called
> MenuPage, which has <wicket:link><a href="StagingPage.html">..., the target
> page of which functions as I explained below. Every time the user goes to
> the MenuPage and clicks on the link, you're saying that Wicket will generate
> a new version of StagingPage in the cache, even with setVersioned(false)? It
> will generate a new ...StagingPage.html?23423414 URL? There is no way to
> turn that off... without essentially rewriting the whole Wicket page request
> and caching mechanism??
>
> This is not good news. I'm not ranting, I'm crying.
>
> Garret
>
>
> On 9/23/2014 8:24 AM, Martin Grigorov wrote:
>>
>> Hi,
>>
>> In short, to accomplish all this you will need several custom impls of
>> Wicket interfaces.
>> 1) custom IRequestMapper that just ignores PageInfo when generating the
>> url
>> for IPageRequestHandler. Search in the archives for
>> "NoVersionRequestMapper"
>> 2) a completely new IPageManager (interface!) that works with Class<Page>
>> instead of with Integer (pageId)
>> So everytime a url is mapped to a page class you should use it to load the
>> Page instance for this class
>>
>> In details:
>> By design only stateless pages do not have the pageId in the url! If a
>> request without pageId comes then a completely new page instance is
>> created.
>> By using something like NoVersionRequestMapper (not supported officially!)
>> only the url for the browser address bar will miss the pageId (see
>> PageAndComponentInfo class), but the pageId is in all link/form urls so
>> clicking/submitting still works. But if the user refreshes the page (F5)
>> then the state is lost!
>>
>> About Page#setVersioned(boolean)
>> This tells Wicket to not increment the pageId after an interaction with
>> the
>> page. A pageId is associated with the page when it is instantiated, but
>> any
>> link click, form submit, etc. won't create a new version of the page. The
>> final result is that every interaction (i.e. state change) with the page
>> will lead to overriding the old one in the page stores.
>> Wicket's IPageStore/IDataStore use API like: put(String sessionId, int
>> pageId, byte[] serializedPage). At the end of every request cycle all
>> rendered stateful pages are stored. If the pageId doesn't change then some
>> old serializedPage would be overriden.
>>
>> For your requirements you will need an API like: put(String sessionId,
>> Class<Page> pageClass, byte[] serializedPage) and byte [] get(String
>> sessionId, Class<Page> pageClass).
>> You can create a IPageManager wrapper that maps sessionId+pageId to
>> pageClass and use that pageClass with custom IMyPageStore and IMyDataStore
>> impls. (Just an idea out of my mind.)
>>
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Tue, Sep 23, 2014 at 3:42 AM, Garret Wilson <ga...@globalmentor.com>
>> wrote:
>>
>>> Can someone explain to me exactly how page versioning works, and how to
>>> turn it off?
>>>
>>> I have a page StagingPage that contains a file uploader. This page is
>>> interesting in that when you upload some files with Button1, the page
>>> lists
>>> the files on the page and keeps them in a collection until you hit
>>> Button2,
>>> at which point the pages does Some Other Really Interesting Thing with
>>> the
>>> files. In other words, the page acts like a staging area for files,
>>> allowing you to 1) upload files and then 2) do something with them.
>>>
>>> I get this number on the end of the URLs which, from the page versioning
>>> and caching reference documentation <http://wicket.apache.org/
>>> guide/guide/versioningCaching.html>, seems to indicate the version of the
>>> page. I don't want this. I just want there to be one version of the page
>>> (even though it is stateful). The back button can go to the previous
>>> page;
>>> I don't care.
>>>
>>> So I turn off versioning in StagingPage with:
>>>
>>>     setVersioned(false);
>>>
>>>
>>> But I still get numbers at the end of the StagingPage URL. Worse, back
>>> and
>>> forward in my browser goes between apparently two versions of the page
>>> (one
>>> with the "Choose Files" button selecting files, and one without)---but
>>> the
>>> number in the URL doesn't change! Worse still, when I remove the number
>>> and
>>> reload the URL without the number, Wicket puts the number back but first
>>> increments the number! Now back and forward cycle between numbered URLs.
>>>
>>> I thought setVersioned(false) was supposed to turn all that off?
>>>
>>> In my own Guise framework, each page has a single component instance tree
>>> on the back end. Whatever you do at that URL, whenever you come back to
>>> it
>>> it will be just like you left it. Granted, there are several drawbacks
>>> such
>>> as memory consumption; Guise can learn a lot from Wicket in how the
>>> latter
>>> can serialize each page between requests, and versioning can be very
>>> useful
>>> in some situations. But here I just want a stateful page that has one
>>> single version---the current version. I don't want it to remember any
>>> previous versions. And I don't want numbers on the end of the URL. How
>>> can
>>> I turn off versioning for real?
>>>
>>> Thanks,
>>>
>>> Garret
>>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: turning off page versioning

[Garret Wilson <ga...@globalmentor.com>]

OMG. What a sad email to wake up to. :(

Let me let all that digest for a while. I never would have imagined a 
situation this dire. Imagine if every time you went to Facebook, it 
generated a new https://www.facebook.com/jdoe?124154451 version! So 
basically Facebook could never use Wicket without rewriting the whole 
page caching scheme. Or LinkedIn. Or... actually, come to think of it, I 
can't even think of a single site that functions like Wicket, 
incrementing some "page version" counter every time you interact with 
the page, so that you can go back to other "versions". (Users don't want 
to go back to other versions! They may want to go back to other /pages/ 
at different URLs, but they realize that interacting with a single pages 
changes the state of that page---they don't expect that other "versions" 
are kept around somewhere.)

Continuing my scenario I outlined earlier, I have an HTML page called 
MenuPage, which has <wicket:link><a href="StagingPage.html">..., the 
target page of which functions as I explained below. Every time the user 
goes to the MenuPage and clicks on the link, you're saying that Wicket 
will generate a new version of StagingPage in the cache, even with 
setVersioned(false)? It will generate a new ...StagingPage.html?23423414 
URL? There is no way to turn that off... without essentially rewriting 
the whole Wicket page request and caching mechanism??

This is not good news. I'm not ranting, I'm crying.

Garret

On 9/23/2014 8:24 AM, Martin Grigorov wrote:
> Hi,
>
> In short, to accomplish all this you will need several custom impls of
> Wicket interfaces.
> 1) custom IRequestMapper that just ignores PageInfo when generating the url
> for IPageRequestHandler. Search in the archives for "NoVersionRequestMapper"
> 2) a completely new IPageManager (interface!) that works with Class<Page>
> instead of with Integer (pageId)
> So everytime a url is mapped to a page class you should use it to load the
> Page instance for this class
>
> In details:
> By design only stateless pages do not have the pageId in the url! If a
> request without pageId comes then a completely new page instance is created.
> By using something like NoVersionRequestMapper (not supported officially!)
> only the url for the browser address bar will miss the pageId (see
> PageAndComponentInfo class), but the pageId is in all link/form urls so
> clicking/submitting still works. But if the user refreshes the page (F5)
> then the state is lost!
>
> About Page#setVersioned(boolean)
> This tells Wicket to not increment the pageId after an interaction with the
> page. A pageId is associated with the page when it is instantiated, but any
> link click, form submit, etc. won't create a new version of the page. The
> final result is that every interaction (i.e. state change) with the page
> will lead to overriding the old one in the page stores.
> Wicket's IPageStore/IDataStore use API like: put(String sessionId, int
> pageId, byte[] serializedPage). At the end of every request cycle all
> rendered stateful pages are stored. If the pageId doesn't change then some
> old serializedPage would be overriden.
>
> For your requirements you will need an API like: put(String sessionId,
> Class<Page> pageClass, byte[] serializedPage) and byte [] get(String
> sessionId, Class<Page> pageClass).
> You can create a IPageManager wrapper that maps sessionId+pageId to
> pageClass and use that pageClass with custom IMyPageStore and IMyDataStore
> impls. (Just an idea out of my mind.)
>
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Tue, Sep 23, 2014 at 3:42 AM, Garret Wilson <ga...@globalmentor.com>
> wrote:
>
>> Can someone explain to me exactly how page versioning works, and how to
>> turn it off?
>>
>> I have a page StagingPage that contains a file uploader. This page is
>> interesting in that when you upload some files with Button1, the page lists
>> the files on the page and keeps them in a collection until you hit Button2,
>> at which point the pages does Some Other Really Interesting Thing with the
>> files. In other words, the page acts like a staging area for files,
>> allowing you to 1) upload files and then 2) do something with them.
>>
>> I get this number on the end of the URLs which, from the page versioning
>> and caching reference documentation <http://wicket.apache.org/
>> guide/guide/versioningCaching.html>, seems to indicate the version of the
>> page. I don't want this. I just want there to be one version of the page
>> (even though it is stateful). The back button can go to the previous page;
>> I don't care.
>>
>> So I turn off versioning in StagingPage with:
>>
>>     setVersioned(false);
>>
>>
>> But I still get numbers at the end of the StagingPage URL. Worse, back and
>> forward in my browser goes between apparently two versions of the page (one
>> with the "Choose Files" button selecting files, and one without)---but the
>> number in the URL doesn't change! Worse still, when I remove the number and
>> reload the URL without the number, Wicket puts the number back but first
>> increments the number! Now back and forward cycle between numbered URLs.
>>
>> I thought setVersioned(false) was supposed to turn all that off?
>>
>> In my own Guise framework, each page has a single component instance tree
>> on the back end. Whatever you do at that URL, whenever you come back to it
>> it will be just like you left it. Granted, there are several drawbacks such
>> as memory consumption; Guise can learn a lot from Wicket in how the latter
>> can serialize each page between requests, and versioning can be very useful
>> in some situations. But here I just want a stateful page that has one
>> single version---the current version. I don't want it to remember any
>> previous versions. And I don't want numbers on the end of the URL. How can
>> I turn off versioning for real?
>>
>> Thanks,
>>
>> Garret
>>

Re: turning off page versioning

[Martin Grigorov <mg...@apache.org>]

Hi,

In short, to accomplish all this you will need several custom impls of
Wicket interfaces.
1) custom IRequestMapper that just ignores PageInfo when generating the url
for IPageRequestHandler. Search in the archives for "NoVersionRequestMapper"
2) a completely new IPageManager (interface!) that works with Class<Page>
instead of with Integer (pageId)
So everytime a url is mapped to a page class you should use it to load the
Page instance for this class

In details:
By design only stateless pages do not have the pageId in the url! If a
request without pageId comes then a completely new page instance is created.
By using something like NoVersionRequestMapper (not supported officially!)
only the url for the browser address bar will miss the pageId (see
PageAndComponentInfo class), but the pageId is in all link/form urls so
clicking/submitting still works. But if the user refreshes the page (F5)
then the state is lost!

About Page#setVersioned(boolean)
This tells Wicket to not increment the pageId after an interaction with the
page. A pageId is associated with the page when it is instantiated, but any
link click, form submit, etc. won't create a new version of the page. The
final result is that every interaction (i.e. state change) with the page
will lead to overriding the old one in the page stores.
Wicket's IPageStore/IDataStore use API like: put(String sessionId, int
pageId, byte[] serializedPage). At the end of every request cycle all
rendered stateful pages are stored. If the pageId doesn't change then some
old serializedPage would be overriden.

For your requirements you will need an API like: put(String sessionId,
Class<Page> pageClass, byte[] serializedPage) and byte [] get(String
sessionId, Class<Page> pageClass).
You can create a IPageManager wrapper that maps sessionId+pageId to
pageClass and use that pageClass with custom IMyPageStore and IMyDataStore
impls. (Just an idea out of my mind.)


Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Tue, Sep 23, 2014 at 3:42 AM, Garret Wilson <ga...@globalmentor.com>
wrote:

> Can someone explain to me exactly how page versioning works, and how to
> turn it off?
>
> I have a page StagingPage that contains a file uploader. This page is
> interesting in that when you upload some files with Button1, the page lists
> the files on the page and keeps them in a collection until you hit Button2,
> at which point the pages does Some Other Really Interesting Thing with the
> files. In other words, the page acts like a staging area for files,
> allowing you to 1) upload files and then 2) do something with them.
>
> I get this number on the end of the URLs which, from the page versioning
> and caching reference documentation <http://wicket.apache.org/
> guide/guide/versioningCaching.html>, seems to indicate the version of the
> page. I don't want this. I just want there to be one version of the page
> (even though it is stateful). The back button can go to the previous page;
> I don't care.
>
> So I turn off versioning in StagingPage with:
>
>    setVersioned(false);
>
>
> But I still get numbers at the end of the StagingPage URL. Worse, back and
> forward in my browser goes between apparently two versions of the page (one
> with the "Choose Files" button selecting files, and one without)---but the
> number in the URL doesn't change! Worse still, when I remove the number and
> reload the URL without the number, Wicket puts the number back but first
> increments the number! Now back and forward cycle between numbered URLs.
>
> I thought setVersioned(false) was supposed to turn all that off?
>
> In my own Guise framework, each page has a single component instance tree
> on the back end. Whatever you do at that URL, whenever you come back to it
> it will be just like you left it. Granted, there are several drawbacks such
> as memory consumption; Guise can learn a lot from Wicket in how the latter
> can serialize each page between requests, and versioning can be very useful
> in some situations. But here I just want a stateful page that has one
> single version---the current version. I don't want it to remember any
> previous versions. And I don't want numbers on the end of the URL. How can
> I turn off versioning for real?
>
> Thanks,
>
> Garret
>