Hi, So far I didn't hear a good explanation why the page id causes you troubles. Most of you are saying "it is ugly". In my previous company we asked some of our users about "wicket:interface=0:1:Something:else:9" and most of them said "I don't care", "I haven't noticed it", etc... And we did this just because one of the technical managers was bothered by it. So it seems only developers really care what is in the the address bar (and bots but this will covered later).
So it is one of those: 1. stateful and "ugly" 2. stateful, pretty and broken 3. stateless and pretty Case 1 is what Igor explained. Case 2 is what Chris, pointbreak and Paolo seems to use in production. See Igor's explanation why it is broken and why your users may loose their state. So don't keep the shopping card (or any other state) in the components! Case 3 is what the bots and not logged in users should see. Bots don't use sessions so don't let them go in the stateful area of your app. They should see the list of products, not the list in their shopping card, right ? @Chris: about your example with previous page and previous state of the shopping card: if you use dynamic models and page caching is disabled then the page will show the components from the previous version but their content will be the last available one. I.e. the shopping card will show what it has to show. On Mon, Mar 19, 2012 at 5:00 AM, Igor Vaynberg <igor.vaynb...@gmail.com> wrote: > On Sun, Mar 18, 2012 at 5:27 PM, Chris Colman > <chr...@stepaheadsoftware.com> wrote: >> I've been thinking about the new 1.5 page ID/versioning feature (which >> we disabled as soon as we discovered it) and wondering if there is >> actually a real world scenario for stateful pages that actually requires >> this functionality. >> >> I understand the purpose is so that the browser's 'Back' function can >> work "properly" (and maybe efficiently) but, in all the scenarios we >> have at least, "proper" would be to re-render and not pull the page from >> the cache. >> >> For example, an online store with the current shopping cart displayed in >> the right hand column: >> >> Browser is showing page for product A, no products in shopping cart >> shown in right column. >> >> User goes to page for product B, adds product B to shopping cart. >> >> Hit's back button. >> >> Now wouldn't the 'page versioning/id' feature now show the cached page >> for product A with a shopping cart that is still empty even though the >> user just added product B? Or would it realize that the shopping cart >> panel's model has changed and update it to reflect the newly added item? >> >> In this scenario showing an empty shopping cart is a very definite >> incorrect behavior that will freak out the user who believes that they >> have added a product B (which they have) but it is not shown in the >> shopping cart. >> >> 1.4 functionality (without page ID) worked fine. We never had a single >> complaint about back button not displaying the correct result. > > i think there is some confusion here. wicket 1.4 had page ids. it also > had page versions. in 1.5 we simply merged page id and page version > into the same variable - page id. this made things much simpler and > also allowed some usecases that were not possible when the two were > separate. > > you dont have to go very far to come up with an example where page id is > useful. > > 1. suppose you have a page with panel A that has a link > 2. user hits a link on the page that swaps panel A for panel B > 3. user presses the back button > 4. user clicks the link on panel A > > now if you turn off page id and therefore page versioning it goes like this > 1. wicket creates page and assigns it id 1 > 2. page id 1 now has panel B instead of panel A > 3. page with id 1 is rerendered > 4. wicket loads page with id 1. user gets an error because it cannot > find the link component the user clicked since the page has panel B > instead of panel A > > now same with page versioning enabled and page caching disabled > > 1. wicket creates page and assigns it id 1 > 2. wicket clones page with id 1 into a new instance with id 2. id 1 > has panel A and id 2 has panel B > 3. wicket renders page with id 1 > 4. wicket loads page with id 1, the link is executed > > now same with page versioning enabled and page caching enabled > > 1. wicket creates page and assigns it id 1 > 2. wicket clones page with id 1 into a new instance with id 2. id 1 > has panel A and id 2 has panel B > 3. browser renders page from cache > 4. wicket loads page with id 1 (page id is encoded in link's url), the > link is executed > > in wicket 1.4 page id would not change but step 2 would increment the > page's version. there would still be two instances of the page: id1 > version 1, id1 version 2 > > now you may be referring to the fact that unlike in 1.4 in 1.5 we > immediately redirect to a versioned url when a bookmarkable url is > accessed.... > > in 1.4 when user hits /mount they would stay on that url > in 1.5 when user hits /mount they are redirected to /mount?2 where 2 > is the next available page id > > in 1.4 a lot of users complained that when the user access a > bookmarkable page and uses ajax to navigate/change the state of the > page all that state is lost when they refresh the page. this is > because when they refresh the page the browser requests the same url > (the bookmarkable one) and a new instance of the page is created. this > is really frustrating to users of ajax-based applications. > > in 1.5 when the user navigates to a mount we immediately redirect to a > statefull url of the new page instance. now when the user makes a > bunch of changes via ajax and presses refresh the page is refreshed > with those changes preserved. > > this is why 1.4 had hybrid url coding strategy, but because it wasnt > the default it still had some usecases that didnt work correctly. > > since most applications use ajax we made this the default behavior of 1.5. > > -igor > > >> >> I'm half doubting whether page ID is a useful feature but half wondering >> if it is a useful feature for which I just haven't discovered useful >> scenarios where it is of benefit and so I should find these scenarios >> and change my design to use it. >> >> Thoughts? >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
