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 <gar...@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
