I am not sure if this is related, but I noticed that occasionally when I click on a link and expect page FOO to render I actually get redirected to a completely unrelated page BAR. This happens when I have a different tab that has page BAR open.
I am using Wicket 1.4.17. Regards, Alec On Thu, Mar 22, 2012 at 11:56 AM, Igor Vaynberg <[email protected]> wrote: > On Thu, Mar 22, 2012 at 10:20 AM, Pointbreak > <[email protected]> wrote: >> On Thu, Mar 22, 2012, at 09:49, Igor Vaynberg wrote: >>> On Thu, Mar 22, 2012 at 8:54 AM, Pointbreak >>> <[email protected]> wrote: >>> > On Thu, Mar 22, 2012, at 08:23, Igor Vaynberg wrote: >>> >> On Thu, Mar 22, 2012 at 7:59 AM, Pointbreak >>> >> <[email protected]> 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. > > suppose i go to /foo > i think click some twistie link that expands some info section, and in > process redirects me to /foo?1 > at this point i think this page is useful and i bookmark it > so i still have the version number in my bookmark. > > in fact, the only way i dont have a version number is if i bookmark > without clicking anything on the page. i dont know how often that > happens compared to bookmarking after at least one click on something > in the page > > -igor > >> 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: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > 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]
