On Thu, Mar 22, 2012, at 14:34, Igor Vaynberg wrote:
> On Thu, Mar 22, 2012 at 1:58 PM, Pointbreak
> <pointbreak+wicketst...@ml1.net> wrote:
> > 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.
>
> its not a new page, its the same page instance.
Yes typo.
> > The NoVersionMount will make sure there is no pageId in the
> > redirected url.
>
> well, thats bad isnt it? because now if i refresh the page the twistie
> would be collapsed again...since wicket will create a new page
> instance because it doesnt have the page id in the url.
No it's good. It's exactly what this mount strategy is about: always
serve an fresh instance of the page on refresh. Users don't randomly
press refresh, and if they do, it's because they think their page is
outdated, in which case they WANT a new page instance. Using the
backbutton will do the same: render a fresh up-to-date version of the
page. It's a different interaction model than Wicket's default, but I
prefer it over what Wicket does. Again: it doesn't fit your described
use case of doing page navigation by swapping out panels. It does fit
many other use cases. And did I mention urls and bookmarks already?
> >> > 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
> >
>
> ---------------------------------------------------------------------
> 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
