On Thu, Mar 22, 2012 at 8:54 AM, Pointbreak <pointbreak+wicketst...@ml1.net> wrote: > On Thu, Mar 22, 2012, at 08:23, Igor Vaynberg wrote: >> On Thu, Mar 22, 2012 at 7:59 AM, Pointbreak >> <pointbreak+wicketst...@ml1.net> wrote: >> > On Sun, Mar 18, 2012, at 20:00, Igor Vaynberg wrote: >> >> 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 >> >> >> > >> > This is imho not what happens with NoVersionMount. What happens is: >> > >> > 1. wicket creates page and assigns it id 1 >> > 2. page id 1 now has panel B instead of panel A >> > 3. wicket creates new page and assigns it id 2; depending on how the >> > page keeps state either a page with panel A and link, or a page with >> > Panel B is created. >> > >> > Hence, there is nothing broken in this scenario. >> >> we were talking about something else here. the NoVersionMount has the >> problem of losing ajax state when the user refreshes the page. >> > > I believe the OP's question was for use-cases were Wickets default > behaviour would be preferred over using a strategy like NoVersionMount. > But if I understood that incorrectly, it's now my question ;-). > Imho > the natural behaviour a user expects for a page-refresh is a fresh > up-to-date version of the page. This is exactly what NoVersionMount does > as it forces a newly constructed page for a refresh. For OP's (Chris > Colman's) shopping card example this seems perfectly reasonable > behaviour.
it is undesirable in applications that perform navigation using ajax panel swapping. in this case a page-refresh will essentially take you back to the homepage. > > I have never had to build a website were it was a problem when the ajax > state was lost on page refresh. but you also have not built every wicket application... > When wicket shows older versions of a > page (e.g. due to back button, bookmarking older versions, etc.), you > have to be really careful with how a page version and a model interact > to not run into trouble. You also loose bookmarkability of such pages > (in the web-browser sense, not in the wicket-sense). you also lose it if the user bookmarks the page after they click something on a bookmarkable page... so stripping the version off initial entry is not fixing the problem entirely. -igor > > --------------------------------------------------------------------- > 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
