On Thu, Mar 22, 2012, at 09:49, Igor Vaynberg wrote: > 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.
Fair enough > > 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... Obviously... to be honest, for your use case (one page ajax application that performs navigation by swapping page components) I have always chosen other frameworks, that are (imho) better suited for these usecases. > > 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. I don't see this. They always get an up-to-date version of the page they bookmarked, as it is always freshly constructed. Ok, I can see the usecase for this page-id/version functionality. However, I still think it would be useful if Wicket also catered for the other usecase, where page navigation is handled by just having multiple pages. Is there a serious flaw in the NoVersionMount strategy for these usecases, and if not, wouldn't something like that be a valuable contribution to Wicket? (In which case I think it should not be turned on by a MountMapper implementation, but by a page property). I have always considered Wicket's main strength the flexibility to have ajax-like functionality in a page based component framework. It's a really nice thing to be able to have support for good looking and bookmarkable url's in such applications. And it also makes page state management easier for these pages (i.e. when a LDM and the component hierarchy on a page have a relation). --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
