On Sun, Mar 18, 2012 at 5:27 PM, Chris Colman <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
