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());
> }
> }
I have to add to my previous mail: There is no reason that TwistieLink
won't work with NoVersionMount. The page is not rendered directly from
the callback url. I just checked this. Wicket does a redirect to the new
page. The NoVersionMount will make sure there is no pageId in the
redirected url.
> > 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
