On Thu, Mar 22, 2012, at 12:30, Igor Vaynberg wrote:
> On Thu, Mar 22, 2012 at 12:24 PM, Pointbreak
> <pointbreak+wicketst...@ml1.net> wrote:
> > On Thu, Mar 22, 2012, at 12:05, Igor Vaynberg wrote:
> >> On Thu, Mar 22, 2012 at 11:55 AM, Pointbreak
> >> <pointbreak+wicketst...@ml1.net> wrote:
> >> > 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.
> >>
> >> the twistie uses a Link which generates a callback url...
> >
> > And the callback for that url directly renders a page? It's probably
> > possible to do that in Wicket somehow, but it's it's not how I use it.
>
> huh? thats how almost every non-ajax action component like Link,
> Button, etc work..
>
> class TwistieLink extends Link {
> private final Component container;
>
> public TwistieLink(String id, Component container) {
> super(id); this.container=container;
> }
>
> protected void onClick() {
> container.setVisible(!container.getVisible());
> }
> }
The purpose of NoVersionMount is to have bookmarkable stateful pages
that use ajax for structural changes to the page. If instead you want to
rerender the page, and don't need it to be bookmarkable, than you should
use the default (but ugly) mount strategy. I personally would always
refactor that TwistieLink in something ajax, to not loose
bookmarkability and to not require a rerender of the entire page.
(I have back on the radar now why the default behavior of wicket is what
it is though).
> > If you really want to do that, don't use something like NoVersionMount
> > for that page... There are a lot of other things you can't do (see the
> > previous mails in this long thread) if you use Wicket default mounting
> > strategy.
> >
> > Not having an id/version in the page urls is how I have always built my
> > Wicket applications. And it always required some sort of hack to do that
> > with Wicket, while I still think a large number of Wicket applications
> > would benefit from it (and to be honest, imho many more existing Wicket
> > applications would have a better user experience if they were build like
> > this). But apparently it's just me and a few others that think like
> > this. Thanks for your feedback.
> >
> >> >> > * 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
