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 <tibokr...@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 <gar...@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 <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 > >>> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
