On Thu, Mar 22, 2012, at 11:42, Igor Vaynberg wrote: > On Thu, Mar 22, 2012 at 11:37 AM, Pointbreak > <pointbreak+wicketst...@ml1.net> wrote: > > On Thu, Mar 22, 2012, at 10:56, Igor Vaynberg wrote: > >> On Thu, Mar 22, 2012 at 10:20 AM, Pointbreak > >> <pointbreak+wicketst...@ml1.net> wrote: > >> > 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. > >> > >> 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 > > > > No that is not what happens with NoVersionMount: > > > > * If you click a link while on /foo that expands an info section why > > would it want to redirect you to /foo?1 ? It should just expand that > > info section, and you can remain on /foo. Doing a redirect defeats the > > purpose of being ajax twistie link.
Not being an ajax twistie link still doesn't add the ?1 to the url. NoVersionMount will only add the id to callback urls. > > * Additionally, if you would explicitly program a redirect to the > > originating page in that callback, there will still be no ?x in the url. > > NoVersionMount drops it. The redirect will however construct a new > > version of the page. Depending on the page implementation, this may mean > > that the info section is not expanded on the final /foo page. > > NoVersionMount also makes sure that url's for callbacks do NOT drop the > > id in the url, so that the page is still stateful for ajax. > > > >> > 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 > > > > --------------------------------------------------------------------- > 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
