No this is bad, i agree with Igor, the latest page should be refreshed, not
reset!
By the way, the hybrid in 1.4 what we are using does look at the mount if
the page doesn't exists any more. And we depend on that, am i reading it
right that we lost that in 1.5?
On Mar 22, 2012 11:12 PM, "Pointbreak" <pointbreak+wicketst...@ml1.net>
wrote:
>
>
> 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
>
>
