What's the point in refreshing if it returns exactly the same page as
before ?
On Thu, Mar 22, 2012 at 11:32 PM, Johan Compagner <jcompag...@gmail.com>wrote:
> 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
> >
> >
>
