You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Chris Colman <ch...@stepaheadsoftware.com> on 2012/03/19 01:27:42 UTC
What real life scenario calls for page ID?
I've been thinking about the new 1.5 page ID/versioning feature (which
we disabled as soon as we discovered it) and wondering if there is
actually a real world scenario for stateful pages that actually requires
this functionality.
I understand the purpose is so that the browser's 'Back' function can
work "properly" (and maybe efficiently) but, in all the scenarios we
have at least, "proper" would be to re-render and not pull the page from
the cache.
For example, an online store with the current shopping cart displayed in
the right hand column:
Browser is showing page for product A, no products in shopping cart
shown in right column.
User goes to page for product B, adds product B to shopping cart.
Hit's back button.
Now wouldn't the 'page versioning/id' feature now show the cached page
for product A with a shopping cart that is still empty even though the
user just added product B? Or would it realize that the shopping cart
panel's model has changed and update it to reflect the newly added item?
In this scenario showing an empty shopping cart is a very definite
incorrect behavior that will freak out the user who believes that they
have added a product B (which they have) but it is not shown in the
shopping cart.
1.4 functionality (without page ID) worked fine. We never had a single
complaint about back button not displaying the correct result.
I'm half doubting whether page ID is a useful feature but half wondering
if it is a useful feature for which I just haven't discovered useful
scenarios where it is of benefit and so I should find these scenarios
and change my design to use it.
Thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Pointbreak <po...@ml1.net>.
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 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Alec Swan <al...@gmail.com>.
I am not sure if this is related, but I noticed that occasionally when
I click on a link and expect page FOO to render I actually get
redirected to a completely unrelated page BAR. This happens when I
have a different tab that has page BAR open.
I am using Wicket 1.4.17.
Regards,
Alec
On Thu, Mar 22, 2012 at 11:56 AM, Igor Vaynberg <ig...@gmail.com> wrote:
> On Thu, Mar 22, 2012 at 10:20 AM, Pointbreak
> <po...@ml1.net> wrote:
>> On Thu, Mar 22, 2012, at 09:49, Igor Vaynberg wrote:
>>> On Thu, Mar 22, 2012 at 8:54 AM, Pointbreak
>>> <po...@ml1.net> wrote:
>>> > On Thu, Mar 22, 2012, at 08:23, Igor Vaynberg wrote:
>>> >> On Thu, Mar 22, 2012 at 7:59 AM, Pointbreak
>>> >> <po...@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
>
> -igor
>
>> 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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Paolo <ir...@gmail.com>.
Alle martedì 27 marzo 2012, Martin Grigorov ha scritto:
> On Tue, Mar 27, 2012 at 12:51 AM, Paolo <ir...@gmail.com> wrote:
> > Alle giovedì 22 marzo 2012, Pointbreak ha scritto:
> >> On Thu, Mar 22, 2012, at 11:42, Igor Vaynberg wrote:
> >
> >> > >
> >> > > No that is not what happens with NoVersionMount:
> >> > >
> >
> >> >
> >> > i didnt say it was an ajax twistie....
> >>
> >> Not being an ajax twistie link still doesn't add the ?1 to the url.
> >> NoVersionMount will only add the id to callback urls.
> >>
> >
> > I am newbie, and all discussion is very hard to understand.
> > I got the code of NoVersionMount and It works fine for me until..
> > ...I migrated to Wicket 6!
> > I change imports:
> > org.apache.wicket.request.mapper.** org.apache.wicket.core.request.mapper.** (OSGi friendly)
> >
> > But I got this error on NoVersionMount:
> >
> > GRAVE: Exception starting filter MainApplication
> > java.lang.IncompatibleClassChangeError: Expecting non-static method org.apache.wicket.core.request.mapper.MountedMapper.getOptionalPlaceholder(Ljava/lang/String;)Ljava/lang/String;
>
> Make sure that all wicket jars are version 6.0.0-beta1 and clean and
> recompile your application against them.
>
I did it correctly. I clean it and recompile, but nothing changed. I got always the same error.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Martin Grigorov <mg...@apache.org>.
On Tue, Mar 27, 2012 at 12:51 AM, Paolo <ir...@gmail.com> wrote:
> Alle giovedì 22 marzo 2012, Pointbreak ha scritto:
>> On Thu, Mar 22, 2012, at 11:42, Igor Vaynberg wrote:
>
>> > >
>> > > No that is not what happens with NoVersionMount:
>> > >
>
>> >
>> > i didnt say it was an ajax twistie....
>>
>> Not being an ajax twistie link still doesn't add the ?1 to the url.
>> NoVersionMount will only add the id to callback urls.
>>
>
> I am newbie, and all discussion is very hard to understand.
> I got the code of NoVersionMount and It works fine for me until..
> ...I migrated to Wicket 6!
> I change imports:
> org.apache.wicket.request.mapper.** org.apache.wicket.core.request.mapper.** (OSGi friendly)
>
> But I got this error on NoVersionMount:
>
> GRAVE: Exception starting filter MainApplication
> java.lang.IncompatibleClassChangeError: Expecting non-static method org.apache.wicket.core.request.mapper.MountedMapper.getOptionalPlaceholder(Ljava/lang/String;)Ljava/lang/String;
Make sure that all wicket jars are version 6.0.0-beta1 and clean and
recompile your application against them.
> at org.apache.wicket.core.request.mapper.MountedMapper.isFixedSegment(MountedMapper.java:228)
> at org.apache.wicket.core.request.mapper.MountedMapper.getPathSegments(MountedMapper.java:207)
> at org.apache.wicket.core.request.mapper.MountedMapper.<init>(MountedMapper.java:196)
> at org.apache.wicket.core.request.mapper.MountedMapper.<init>(MountedMapper.java:175)
> at org.apache.wicket.examples.authentication3.NoVersionMount.<init>(MainApplication.java:90)
> at org.apache.wicket.examples.authentication3.MainApplication.init(MainApplication.java:77)
> at org.apache.wicket.Application.initApplication(Application.java:801)
> at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:344)
> at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:284)
> at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:295)
> at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:422)
> at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:115)
> at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3838)
> at org.apache.catalina.core.StandardContext.start(StandardContext.java:4488)
> at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
> at org.apache.catalina.core.StandardHost.start(StandardHost.java:722)
> at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
> at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
> at org.apache.catalina.core.StandardService.start(StandardService.java:516)
> at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
> at org.apache.catalina.startup.Catalina.start(Catalina.java:593)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)
> 27-mar-2012 0.30.55 org.apache.catalina.core.StandardContext start
> GRAVE: Error filterStart
> 27-mar-2012 0.30.55 org.apache.catalina.core.StandardContext start
> GRAVE: Context [/watch] startup failed due to previous errors
> 27-mar-2012 0.30.55 org.apache.catalina.loader.WebappClassLoader clearReferencesJdbc
> GRAVE: A web application registered the JBDC driver [com.mysql.jdbc.Driver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
>
>
> And this is my import list in MainApplication.java:
>
> package org.apache.wicket.examples.authentication3;
>
> import org.apache.wicket.protocol.http.WebApplication;
> import org.apache.wicket.Page;
> import org.apache.wicket.authroles.authentication.AbstractAuthenticatedWebSession;
> import org.apache.wicket.authroles.authentication.AuthenticatedWebApplication;
> import org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler;
> import org.apache.wicket.core.request.mapper.MountedMapper;
> import org.apache.wicket.markup.html.SecurePackageResourceGuard;
> import org.apache.wicket.markup.html.WebPage;
> import org.apache.wicket.Application;
> import org.apache.wicket.Page;
> import org.apache.wicket.request.IRequestHandler;
> import org.apache.wicket.request.Request;
> import org.apache.wicket.request.Response;
> import org.apache.wicket.request.Url;
> import org.apache.wicket.Session;
> import org.apache.wicket.protocol.http.WebApplication;
> import org.apache.wicket.core.request.*;
> import org.apache.wicket.request.component.IRequestablePage;
> import org.apache.wicket.request.mapper.info.PageComponentInfo;
> import org.apache.wicket.request.mapper.parameter.PageParametersEncoder;
> //import org.apache.wicket.request.handler.ListenerInterfaceRequestHandler;
> //import org.apache.wicket.request.mapper.MountedMapper;
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Paolo <ir...@gmail.com>.
Alle giovedì 22 marzo 2012, Pointbreak ha scritto:
> On Thu, Mar 22, 2012, at 11:42, Igor Vaynberg wrote:
> > >
> > > No that is not what happens with NoVersionMount:
> > >
> >
> > i didnt say it was an ajax twistie....
>
> Not being an ajax twistie link still doesn't add the ?1 to the url.
> NoVersionMount will only add the id to callback urls.
>
I am newbie, and all discussion is very hard to understand.
I got the code of NoVersionMount and It works fine for me until..
...I migrated to Wicket 6!
I change imports:
org.apache.wicket.request.mapper.** org.apache.wicket.core.request.mapper.** (OSGi friendly)
But I got this error on NoVersionMount:
GRAVE: Exception starting filter MainApplication
java.lang.IncompatibleClassChangeError: Expecting non-static method org.apache.wicket.core.request.mapper.MountedMapper.getOptionalPlaceholder(Ljava/lang/String;)Ljava/lang/String;
at org.apache.wicket.core.request.mapper.MountedMapper.isFixedSegment(MountedMapper.java:228)
at org.apache.wicket.core.request.mapper.MountedMapper.getPathSegments(MountedMapper.java:207)
at org.apache.wicket.core.request.mapper.MountedMapper.<init>(MountedMapper.java:196)
at org.apache.wicket.core.request.mapper.MountedMapper.<init>(MountedMapper.java:175)
at org.apache.wicket.examples.authentication3.NoVersionMount.<init>(MainApplication.java:90)
at org.apache.wicket.examples.authentication3.MainApplication.init(MainApplication.java:77)
at org.apache.wicket.Application.initApplication(Application.java:801)
at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:344)
at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:284)
at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:295)
at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:422)
at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:115)
at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3838)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4488)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:722)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at org.apache.catalina.core.StandardService.start(StandardService.java:516)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:593)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)
27-mar-2012 0.30.55 org.apache.catalina.core.StandardContext start
GRAVE: Error filterStart
27-mar-2012 0.30.55 org.apache.catalina.core.StandardContext start
GRAVE: Context [/watch] startup failed due to previous errors
27-mar-2012 0.30.55 org.apache.catalina.loader.WebappClassLoader clearReferencesJdbc
GRAVE: A web application registered the JBDC driver [com.mysql.jdbc.Driver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
And this is my import list in MainApplication.java:
package org.apache.wicket.examples.authentication3;
import org.apache.wicket.protocol.http.WebApplication;
import org.apache.wicket.Page;
import org.apache.wicket.authroles.authentication.AbstractAuthenticatedWebSession;
import org.apache.wicket.authroles.authentication.AuthenticatedWebApplication;
import org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler;
import org.apache.wicket.core.request.mapper.MountedMapper;
import org.apache.wicket.markup.html.SecurePackageResourceGuard;
import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.Application;
import org.apache.wicket.Page;
import org.apache.wicket.request.IRequestHandler;
import org.apache.wicket.request.Request;
import org.apache.wicket.request.Response;
import org.apache.wicket.request.Url;
import org.apache.wicket.Session;
import org.apache.wicket.protocol.http.WebApplication;
import org.apache.wicket.core.request.*;
import org.apache.wicket.request.component.IRequestablePage;
import org.apache.wicket.request.mapper.info.PageComponentInfo;
import org.apache.wicket.request.mapper.parameter.PageParametersEncoder;
//import org.apache.wicket.request.handler.ListenerInterfaceRequestHandler;
//import org.apache.wicket.request.mapper.MountedMapper;
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Gerjon de Vries <ge...@pointbreak.biz>.
On Thu, Mar 22, 2012, at 11:42, Igor Vaynberg wrote:
> On Thu, Mar 22, 2012 at 11:37 AM, Pointbreak
> <po...@ml1.net> wrote:
> > On Thu, Mar 22, 2012, at 10:56, Igor Vaynberg wrote:
> >> On Thu, Mar 22, 2012 at 10:20 AM, Pointbreak
> >> <po...@ml1.net> wrote:
> >> > On Thu, Mar 22, 2012, at 09:49, Igor Vaynberg wrote:
> >> >> On Thu, Mar 22, 2012 at 8:54 AM, Pointbreak
> >> >> <po...@ml1.net> wrote:
> >> >> > On Thu, Mar 22, 2012, at 08:23, Igor Vaynberg wrote:
> >> >> >> On Thu, Mar 22, 2012 at 7:59 AM, Pointbreak
> >> >> >> <po...@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.
> > * 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-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Pointbreak <po...@ml1.net>.
On Thu, Mar 22, 2012, at 11:42, Igor Vaynberg wrote:
> On Thu, Mar 22, 2012 at 11:37 AM, Pointbreak
> <po...@ml1.net> wrote:
> > On Thu, Mar 22, 2012, at 10:56, Igor Vaynberg wrote:
> >> On Thu, Mar 22, 2012 at 10:20 AM, Pointbreak
> >> <po...@ml1.net> wrote:
> >> > On Thu, Mar 22, 2012, at 09:49, Igor Vaynberg wrote:
> >> >> On Thu, Mar 22, 2012 at 8:54 AM, Pointbreak
> >> >> <po...@ml1.net> wrote:
> >> >> > On Thu, Mar 22, 2012, at 08:23, Igor Vaynberg wrote:
> >> >> >> On Thu, Mar 22, 2012 at 7:59 AM, Pointbreak
> >> >> >> <po...@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.
>
> i didnt say it was an ajax twistie....
Not being an ajax twistie link still doesn't add the ?1 to the url.
NoVersionMount will only add the id to callback urls.
>
> >
> > * 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-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Igor Vaynberg <ig...@gmail.com>.
i dont think we lost it. something in my app here made it work weird,
but i couldnt repro in a quickstart.
-igor
On Thu, Mar 22, 2012 at 3:32 PM, Johan Compagner <jc...@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" <po...@ml1.net>
> wrote:
>
>>
>>
>> On Thu, Mar 22, 2012, at 14:34, Igor Vaynberg wrote:
>> > On Thu, Mar 22, 2012 at 1:58 PM, Pointbreak
>> > <po...@ml1.net> wrote:
>> > > On Thu, Mar 22, 2012, at 12:30, Igor Vaynberg wrote:
>> > >> On Thu, Mar 22, 2012 at 12:24 PM, Pointbreak
>> > >> <po...@ml1.net> wrote:
>> > >> > On Thu, Mar 22, 2012, at 12:05, Igor Vaynberg wrote:
>> > >> >> On Thu, Mar 22, 2012 at 11:55 AM, Pointbreak
>> > >> >> <po...@ml1.net> wrote:
>> > >> >> > On Thu, Mar 22, 2012, at 11:42, Igor Vaynberg wrote:
>> > >> >> >> On Thu, Mar 22, 2012 at 11:37 AM, Pointbreak
>> > >> >> >> <po...@ml1.net> wrote:
>> > >> >> >> > On Thu, Mar 22, 2012, at 10:56, Igor Vaynberg wrote:
>> > >> >> >> >> On Thu, Mar 22, 2012 at 10:20 AM, Pointbreak
>> > >> >> >> >> <po...@ml1.net> wrote:
>> > >> >> >> >> > On Thu, Mar 22, 2012, at 09:49, Igor Vaynberg wrote:
>> > >> >> >> >> >> On Thu, Mar 22, 2012 at 8:54 AM, Pointbreak
>> > >> >> >> >> >> <po...@ml1.net> wrote:
>> > >> >> >> >> >> > On Thu, Mar 22, 2012, at 08:23, Igor Vaynberg wrote:
>> > >> >> >> >> >> >> On Thu, Mar 22, 2012 at 7:59 AM, Pointbreak
>> > >> >> >> >> >> >> <po...@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-unsubscribe@wicket.apache.org
>> > >> > For additional commands, e-mail: users-help@wicket.apache.org
>> > >> >
>> > >>
>> > >> ---------------------------------------------------------------------
>> > >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > >> For additional commands, e-mail: users-help@wicket.apache.org
>> > >>
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > > For additional commands, e-mail: users-help@wicket.apache.org
>> > >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Pointbreak <po...@ml1.net>.
On Thu, Mar 22, 2012, at 15:46, Igor Vaynberg wrote:
> On Thu, Mar 22, 2012 at 3:39 PM, heikki <tr...@gmail.com> wrote:
> > What's the point in refreshing if it returns exactly the same page as
> > before ?
>
> it allows components such as datatables and others that pull data from
> the database to refresh, while preserving other things.
>
> think of it this way:
>
> i have a page with two tabs. the first tab shows a table of data, and
> the second tab shows the graph of data.
> i load the page through a bookmarkable page and switch to the second
> tab to look at the graph.
>
> ten minutes later i want to refresh the graph, so i refresh the page.
> but now, instead of looking at the graph i am looking at the table
> again because in the new instance of the page the first tab is
> selected.
>
> what if it takes me three or four clicks to get to the graph? it is
> very frustrating to lose your navigation just because you refreshed
>
> another example is a log viewer. suppose i have a form on the top that
> lets me select a way to filter log entries such as thread name and
> severity. i say i want to look at warnings and up from the worker 15
> thread. the table below filters the log. ten minutes later i want to
> see new log entries, so i refresh. but because a new page instance is
> created i have to reselect the severity and thread name.
Ok, and now split the above use cases over two sessions. Load the page,
turn to the required tabs, filter log entries like you want etc. Then
bookmark, and the next day at some point open the page from the
bookmark, expecting not having the described frustrations. But you will
have exactly the frustrations described above, and more: the page
instance you will be looking at depends on what you did in your current
session at some point, as the bookmark possibly refers to an old page
id. To a user this is completely random.
Hence we use the NoVersionMount, and model the UI changes you described
either via page parameters, in server side user-preferences, or in the
client side (web browser) state. Solving both what you describe above
and making it possible to bookmark that between sessions.
Again: it's not for every app. It's nice that wicket can keep such state
automatically for you. But doing that has drawbacks as well, listed by
some in this thread. It would be nice to have NoVersionMount like
functionality more easily available. Unless of course it's broken, but
so far it doesn't seem to be.
And now I go for a beer, and will forget this thread for at least a very
long sunny spring weekend.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Igor Vaynberg <ig...@gmail.com>.
On Thu, Mar 22, 2012 at 3:39 PM, heikki <tr...@gmail.com> wrote:
> What's the point in refreshing if it returns exactly the same page as
> before ?
it allows components such as datatables and others that pull data from
the database to refresh, while preserving other things.
think of it this way:
i have a page with two tabs. the first tab shows a table of data, and
the second tab shows the graph of data.
i load the page through a bookmarkable page and switch to the second
tab to look at the graph.
ten minutes later i want to refresh the graph, so i refresh the page.
but now, instead of looking at the graph i am looking at the table
again because in the new instance of the page the first tab is
selected.
what if it takes me three or four clicks to get to the graph? it is
very frustrating to lose your navigation just because you refreshed
another example is a log viewer. suppose i have a form on the top that
lets me select a way to filter log entries such as thread name and
severity. i say i want to look at warnings and up from the worker 15
thread. the table below filters the log. ten minutes later i want to
see new log entries, so i refresh. but because a new page instance is
created i have to reselect the severity and thread name.
-igor
>
>
>
> On Thu, Mar 22, 2012 at 11:32 PM, Johan Compagner <jc...@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" <po...@ml1.net>
>> wrote:
>>
>> >
>> >
>> > On Thu, Mar 22, 2012, at 14:34, Igor Vaynberg wrote:
>> > > On Thu, Mar 22, 2012 at 1:58 PM, Pointbreak
>> > > <po...@ml1.net> wrote:
>> > > > On Thu, Mar 22, 2012, at 12:30, Igor Vaynberg wrote:
>> > > >> On Thu, Mar 22, 2012 at 12:24 PM, Pointbreak
>> > > >> <po...@ml1.net> wrote:
>> > > >> > On Thu, Mar 22, 2012, at 12:05, Igor Vaynberg wrote:
>> > > >> >> On Thu, Mar 22, 2012 at 11:55 AM, Pointbreak
>> > > >> >> <po...@ml1.net> wrote:
>> > > >> >> > On Thu, Mar 22, 2012, at 11:42, Igor Vaynberg wrote:
>> > > >> >> >> On Thu, Mar 22, 2012 at 11:37 AM, Pointbreak
>> > > >> >> >> <po...@ml1.net> wrote:
>> > > >> >> >> > On Thu, Mar 22, 2012, at 10:56, Igor Vaynberg wrote:
>> > > >> >> >> >> On Thu, Mar 22, 2012 at 10:20 AM, Pointbreak
>> > > >> >> >> >> <po...@ml1.net> wrote:
>> > > >> >> >> >> > On Thu, Mar 22, 2012, at 09:49, Igor Vaynberg wrote:
>> > > >> >> >> >> >> On Thu, Mar 22, 2012 at 8:54 AM, Pointbreak
>> > > >> >> >> >> >> <po...@ml1.net> wrote:
>> > > >> >> >> >> >> > On Thu, Mar 22, 2012, at 08:23, Igor Vaynberg wrote:
>> > > >> >> >> >> >> >> On Thu, Mar 22, 2012 at 7:59 AM, Pointbreak
>> > > >> >> >> >> >> >> <po...@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-unsubscribe@wicket.apache.org
>> > > >> > For additional commands, e-mail: users-help@wicket.apache.org
>> > > >> >
>> > > >>
>> > > >>
>> ---------------------------------------------------------------------
>> > > >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > > >> For additional commands, e-mail: users-help@wicket.apache.org
>> > > >>
>> > > >
>> > > > ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > > > For additional commands, e-mail: users-help@wicket.apache.org
>> > > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > > For additional commands, e-mail: users-help@wicket.apache.org
>> > >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by heikki <tr...@gmail.com>.
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 <jc...@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" <po...@ml1.net>
> wrote:
>
> >
> >
> > On Thu, Mar 22, 2012, at 14:34, Igor Vaynberg wrote:
> > > On Thu, Mar 22, 2012 at 1:58 PM, Pointbreak
> > > <po...@ml1.net> wrote:
> > > > On Thu, Mar 22, 2012, at 12:30, Igor Vaynberg wrote:
> > > >> On Thu, Mar 22, 2012 at 12:24 PM, Pointbreak
> > > >> <po...@ml1.net> wrote:
> > > >> > On Thu, Mar 22, 2012, at 12:05, Igor Vaynberg wrote:
> > > >> >> On Thu, Mar 22, 2012 at 11:55 AM, Pointbreak
> > > >> >> <po...@ml1.net> wrote:
> > > >> >> > On Thu, Mar 22, 2012, at 11:42, Igor Vaynberg wrote:
> > > >> >> >> On Thu, Mar 22, 2012 at 11:37 AM, Pointbreak
> > > >> >> >> <po...@ml1.net> wrote:
> > > >> >> >> > On Thu, Mar 22, 2012, at 10:56, Igor Vaynberg wrote:
> > > >> >> >> >> On Thu, Mar 22, 2012 at 10:20 AM, Pointbreak
> > > >> >> >> >> <po...@ml1.net> wrote:
> > > >> >> >> >> > On Thu, Mar 22, 2012, at 09:49, Igor Vaynberg wrote:
> > > >> >> >> >> >> On Thu, Mar 22, 2012 at 8:54 AM, Pointbreak
> > > >> >> >> >> >> <po...@ml1.net> wrote:
> > > >> >> >> >> >> > On Thu, Mar 22, 2012, at 08:23, Igor Vaynberg wrote:
> > > >> >> >> >> >> >> On Thu, Mar 22, 2012 at 7:59 AM, Pointbreak
> > > >> >> >> >> >> >> <po...@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-unsubscribe@wicket.apache.org
> > > >> > For additional commands, e-mail: users-help@wicket.apache.org
> > > >> >
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > >> For additional commands, e-mail: users-help@wicket.apache.org
> > > >>
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
Re: What real life scenario calls for page ID?
Posted by Johan Compagner <jc...@gmail.com>.
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" <po...@ml1.net>
wrote:
>
>
> On Thu, Mar 22, 2012, at 14:34, Igor Vaynberg wrote:
> > On Thu, Mar 22, 2012 at 1:58 PM, Pointbreak
> > <po...@ml1.net> wrote:
> > > On Thu, Mar 22, 2012, at 12:30, Igor Vaynberg wrote:
> > >> On Thu, Mar 22, 2012 at 12:24 PM, Pointbreak
> > >> <po...@ml1.net> wrote:
> > >> > On Thu, Mar 22, 2012, at 12:05, Igor Vaynberg wrote:
> > >> >> On Thu, Mar 22, 2012 at 11:55 AM, Pointbreak
> > >> >> <po...@ml1.net> wrote:
> > >> >> > On Thu, Mar 22, 2012, at 11:42, Igor Vaynberg wrote:
> > >> >> >> On Thu, Mar 22, 2012 at 11:37 AM, Pointbreak
> > >> >> >> <po...@ml1.net> wrote:
> > >> >> >> > On Thu, Mar 22, 2012, at 10:56, Igor Vaynberg wrote:
> > >> >> >> >> On Thu, Mar 22, 2012 at 10:20 AM, Pointbreak
> > >> >> >> >> <po...@ml1.net> wrote:
> > >> >> >> >> > On Thu, Mar 22, 2012, at 09:49, Igor Vaynberg wrote:
> > >> >> >> >> >> On Thu, Mar 22, 2012 at 8:54 AM, Pointbreak
> > >> >> >> >> >> <po...@ml1.net> wrote:
> > >> >> >> >> >> > On Thu, Mar 22, 2012, at 08:23, Igor Vaynberg wrote:
> > >> >> >> >> >> >> On Thu, Mar 22, 2012 at 7:59 AM, Pointbreak
> > >> >> >> >> >> >> <po...@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-unsubscribe@wicket.apache.org
> > >> > For additional commands, e-mail: users-help@wicket.apache.org
> > >> >
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > >> For additional commands, e-mail: users-help@wicket.apache.org
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: What real life scenario calls for page ID?
Posted by Pointbreak <po...@ml1.net>.
On Thu, Mar 22, 2012, at 14:34, Igor Vaynberg wrote:
> On Thu, Mar 22, 2012 at 1:58 PM, Pointbreak
> <po...@ml1.net> wrote:
> > On Thu, Mar 22, 2012, at 12:30, Igor Vaynberg wrote:
> >> On Thu, Mar 22, 2012 at 12:24 PM, Pointbreak
> >> <po...@ml1.net> wrote:
> >> > On Thu, Mar 22, 2012, at 12:05, Igor Vaynberg wrote:
> >> >> On Thu, Mar 22, 2012 at 11:55 AM, Pointbreak
> >> >> <po...@ml1.net> wrote:
> >> >> > On Thu, Mar 22, 2012, at 11:42, Igor Vaynberg wrote:
> >> >> >> On Thu, Mar 22, 2012 at 11:37 AM, Pointbreak
> >> >> >> <po...@ml1.net> wrote:
> >> >> >> > On Thu, Mar 22, 2012, at 10:56, Igor Vaynberg wrote:
> >> >> >> >> On Thu, Mar 22, 2012 at 10:20 AM, Pointbreak
> >> >> >> >> <po...@ml1.net> wrote:
> >> >> >> >> > On Thu, Mar 22, 2012, at 09:49, Igor Vaynberg wrote:
> >> >> >> >> >> On Thu, Mar 22, 2012 at 8:54 AM, Pointbreak
> >> >> >> >> >> <po...@ml1.net> wrote:
> >> >> >> >> >> > On Thu, Mar 22, 2012, at 08:23, Igor Vaynberg wrote:
> >> >> >> >> >> >> On Thu, Mar 22, 2012 at 7:59 AM, Pointbreak
> >> >> >> >> >> >> <po...@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-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Igor Vaynberg <ig...@gmail.com>.
On Thu, Mar 22, 2012 at 1:58 PM, Pointbreak
<po...@ml1.net> wrote:
> On Thu, Mar 22, 2012, at 12:30, Igor Vaynberg wrote:
>> On Thu, Mar 22, 2012 at 12:24 PM, Pointbreak
>> <po...@ml1.net> wrote:
>> > On Thu, Mar 22, 2012, at 12:05, Igor Vaynberg wrote:
>> >> On Thu, Mar 22, 2012 at 11:55 AM, Pointbreak
>> >> <po...@ml1.net> wrote:
>> >> > On Thu, Mar 22, 2012, at 11:42, Igor Vaynberg wrote:
>> >> >> On Thu, Mar 22, 2012 at 11:37 AM, Pointbreak
>> >> >> <po...@ml1.net> wrote:
>> >> >> > On Thu, Mar 22, 2012, at 10:56, Igor Vaynberg wrote:
>> >> >> >> On Thu, Mar 22, 2012 at 10:20 AM, Pointbreak
>> >> >> >> <po...@ml1.net> wrote:
>> >> >> >> > On Thu, Mar 22, 2012, at 09:49, Igor Vaynberg wrote:
>> >> >> >> >> On Thu, Mar 22, 2012 at 8:54 AM, Pointbreak
>> >> >> >> >> <po...@ml1.net> wrote:
>> >> >> >> >> > On Thu, Mar 22, 2012, at 08:23, Igor Vaynberg wrote:
>> >> >> >> >> >> On Thu, Mar 22, 2012 at 7:59 AM, Pointbreak
>> >> >> >> >> >> <po...@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.
> 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.
-igor
>
>> > 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-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Pointbreak <po...@ml1.net>.
On Thu, Mar 22, 2012, at 12:30, Igor Vaynberg wrote:
> On Thu, Mar 22, 2012 at 12:24 PM, Pointbreak
> <po...@ml1.net> wrote:
> > On Thu, Mar 22, 2012, at 12:05, Igor Vaynberg wrote:
> >> On Thu, Mar 22, 2012 at 11:55 AM, Pointbreak
> >> <po...@ml1.net> wrote:
> >> > On Thu, Mar 22, 2012, at 11:42, Igor Vaynberg wrote:
> >> >> On Thu, Mar 22, 2012 at 11:37 AM, Pointbreak
> >> >> <po...@ml1.net> wrote:
> >> >> > On Thu, Mar 22, 2012, at 10:56, Igor Vaynberg wrote:
> >> >> >> On Thu, Mar 22, 2012 at 10:20 AM, Pointbreak
> >> >> >> <po...@ml1.net> wrote:
> >> >> >> > On Thu, Mar 22, 2012, at 09:49, Igor Vaynberg wrote:
> >> >> >> >> On Thu, Mar 22, 2012 at 8:54 AM, Pointbreak
> >> >> >> >> <po...@ml1.net> wrote:
> >> >> >> >> > On Thu, Mar 22, 2012, at 08:23, Igor Vaynberg wrote:
> >> >> >> >> >> On Thu, Mar 22, 2012 at 7:59 AM, Pointbreak
> >> >> >> >> >> <po...@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-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Pointbreak <po...@ml1.net>.
On Thu, Mar 22, 2012, at 12:30, Igor Vaynberg wrote:
> On Thu, Mar 22, 2012 at 12:24 PM, Pointbreak
> <po...@ml1.net> wrote:
> > On Thu, Mar 22, 2012, at 12:05, Igor Vaynberg wrote:
> >> On Thu, Mar 22, 2012 at 11:55 AM, Pointbreak
> >> <po...@ml1.net> wrote:
> >> > On Thu, Mar 22, 2012, at 11:42, Igor Vaynberg wrote:
> >> >> On Thu, Mar 22, 2012 at 11:37 AM, Pointbreak
> >> >> <po...@ml1.net> wrote:
> >> >> > On Thu, Mar 22, 2012, at 10:56, Igor Vaynberg wrote:
> >> >> >> On Thu, Mar 22, 2012 at 10:20 AM, Pointbreak
> >> >> >> <po...@ml1.net> wrote:
> >> >> >> > On Thu, Mar 22, 2012, at 09:49, Igor Vaynberg wrote:
> >> >> >> >> On Thu, Mar 22, 2012 at 8:54 AM, Pointbreak
> >> >> >> >> <po...@ml1.net> wrote:
> >> >> >> >> > On Thu, Mar 22, 2012, at 08:23, Igor Vaynberg wrote:
> >> >> >> >> >> On Thu, Mar 22, 2012 at 7:59 AM, Pointbreak
> >> >> >> >> >> <po...@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-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Igor Vaynberg <ig...@gmail.com>.
On Thu, Mar 22, 2012 at 12:24 PM, Pointbreak
<po...@ml1.net> wrote:
> On Thu, Mar 22, 2012, at 12:05, Igor Vaynberg wrote:
>> On Thu, Mar 22, 2012 at 11:55 AM, Pointbreak
>> <po...@ml1.net> wrote:
>> > On Thu, Mar 22, 2012, at 11:42, Igor Vaynberg wrote:
>> >> On Thu, Mar 22, 2012 at 11:37 AM, Pointbreak
>> >> <po...@ml1.net> wrote:
>> >> > On Thu, Mar 22, 2012, at 10:56, Igor Vaynberg wrote:
>> >> >> On Thu, Mar 22, 2012 at 10:20 AM, Pointbreak
>> >> >> <po...@ml1.net> wrote:
>> >> >> > On Thu, Mar 22, 2012, at 09:49, Igor Vaynberg wrote:
>> >> >> >> On Thu, Mar 22, 2012 at 8:54 AM, Pointbreak
>> >> >> >> <po...@ml1.net> wrote:
>> >> >> >> > On Thu, Mar 22, 2012, at 08:23, Igor Vaynberg wrote:
>> >> >> >> >> On Thu, Mar 22, 2012 at 7:59 AM, Pointbreak
>> >> >> >> >> <po...@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());
}
}
-igor
> 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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Pointbreak <po...@ml1.net>.
On Thu, Mar 22, 2012, at 12:05, Igor Vaynberg wrote:
> On Thu, Mar 22, 2012 at 11:55 AM, Pointbreak
> <po...@ml1.net> wrote:
> > On Thu, Mar 22, 2012, at 11:42, Igor Vaynberg wrote:
> >> On Thu, Mar 22, 2012 at 11:37 AM, Pointbreak
> >> <po...@ml1.net> wrote:
> >> > On Thu, Mar 22, 2012, at 10:56, Igor Vaynberg wrote:
> >> >> On Thu, Mar 22, 2012 at 10:20 AM, Pointbreak
> >> >> <po...@ml1.net> wrote:
> >> >> > On Thu, Mar 22, 2012, at 09:49, Igor Vaynberg wrote:
> >> >> >> On Thu, Mar 22, 2012 at 8:54 AM, Pointbreak
> >> >> >> <po...@ml1.net> wrote:
> >> >> >> > On Thu, Mar 22, 2012, at 08:23, Igor Vaynberg wrote:
> >> >> >> >> On Thu, Mar 22, 2012 at 7:59 AM, Pointbreak
> >> >> >> >> <po...@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.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Igor Vaynberg <ig...@gmail.com>.
On Thu, Mar 22, 2012 at 11:55 AM, Pointbreak
<po...@ml1.net> wrote:
> On Thu, Mar 22, 2012, at 11:42, Igor Vaynberg wrote:
>> On Thu, Mar 22, 2012 at 11:37 AM, Pointbreak
>> <po...@ml1.net> wrote:
>> > On Thu, Mar 22, 2012, at 10:56, Igor Vaynberg wrote:
>> >> On Thu, Mar 22, 2012 at 10:20 AM, Pointbreak
>> >> <po...@ml1.net> wrote:
>> >> > On Thu, Mar 22, 2012, at 09:49, Igor Vaynberg wrote:
>> >> >> On Thu, Mar 22, 2012 at 8:54 AM, Pointbreak
>> >> >> <po...@ml1.net> wrote:
>> >> >> > On Thu, Mar 22, 2012, at 08:23, Igor Vaynberg wrote:
>> >> >> >> On Thu, Mar 22, 2012 at 7:59 AM, Pointbreak
>> >> >> >> <po...@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...
-igor
>
>> > * 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-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Pointbreak <po...@ml1.net>.
On Thu, Mar 22, 2012, at 11:42, Igor Vaynberg wrote:
> On Thu, Mar 22, 2012 at 11:37 AM, Pointbreak
> <po...@ml1.net> wrote:
> > On Thu, Mar 22, 2012, at 10:56, Igor Vaynberg wrote:
> >> On Thu, Mar 22, 2012 at 10:20 AM, Pointbreak
> >> <po...@ml1.net> wrote:
> >> > On Thu, Mar 22, 2012, at 09:49, Igor Vaynberg wrote:
> >> >> On Thu, Mar 22, 2012 at 8:54 AM, Pointbreak
> >> >> <po...@ml1.net> wrote:
> >> >> > On Thu, Mar 22, 2012, at 08:23, Igor Vaynberg wrote:
> >> >> >> On Thu, Mar 22, 2012 at 7:59 AM, Pointbreak
> >> >> >> <po...@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.
> > * 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-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Igor Vaynberg <ig...@gmail.com>.
On Thu, Mar 22, 2012 at 11:37 AM, Pointbreak
<po...@ml1.net> wrote:
> On Thu, Mar 22, 2012, at 10:56, Igor Vaynberg wrote:
>> On Thu, Mar 22, 2012 at 10:20 AM, Pointbreak
>> <po...@ml1.net> wrote:
>> > On Thu, Mar 22, 2012, at 09:49, Igor Vaynberg wrote:
>> >> On Thu, Mar 22, 2012 at 8:54 AM, Pointbreak
>> >> <po...@ml1.net> wrote:
>> >> > On Thu, Mar 22, 2012, at 08:23, Igor Vaynberg wrote:
>> >> >> On Thu, Mar 22, 2012 at 7:59 AM, Pointbreak
>> >> >> <po...@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.
i didnt say it was an ajax twistie....
-igor
>
> * 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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Pointbreak <po...@ml1.net>.
On Thu, Mar 22, 2012, at 10:56, Igor Vaynberg wrote:
> On Thu, Mar 22, 2012 at 10:20 AM, Pointbreak
> <po...@ml1.net> wrote:
> > On Thu, Mar 22, 2012, at 09:49, Igor Vaynberg wrote:
> >> On Thu, Mar 22, 2012 at 8:54 AM, Pointbreak
> >> <po...@ml1.net> wrote:
> >> > On Thu, Mar 22, 2012, at 08:23, Igor Vaynberg wrote:
> >> >> On Thu, Mar 22, 2012 at 7:59 AM, Pointbreak
> >> >> <po...@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.
* 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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Igor Vaynberg <ig...@gmail.com>.
On Thu, Mar 22, 2012 at 10:20 AM, Pointbreak
<po...@ml1.net> wrote:
> On Thu, Mar 22, 2012, at 09:49, Igor Vaynberg wrote:
>> On Thu, Mar 22, 2012 at 8:54 AM, Pointbreak
>> <po...@ml1.net> wrote:
>> > On Thu, Mar 22, 2012, at 08:23, Igor Vaynberg wrote:
>> >> On Thu, Mar 22, 2012 at 7:59 AM, Pointbreak
>> >> <po...@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
-igor
> 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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Pointbreak <po...@ml1.net>.
On Thu, Mar 22, 2012, at 09:49, Igor Vaynberg wrote:
> On Thu, Mar 22, 2012 at 8:54 AM, Pointbreak
> <po...@ml1.net> wrote:
> > On Thu, Mar 22, 2012, at 08:23, Igor Vaynberg wrote:
> >> On Thu, Mar 22, 2012 at 7:59 AM, Pointbreak
> >> <po...@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.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Igor Vaynberg <ig...@gmail.com>.
On Thu, Mar 22, 2012 at 8:54 AM, Pointbreak
<po...@ml1.net> wrote:
> On Thu, Mar 22, 2012, at 08:23, Igor Vaynberg wrote:
>> On Thu, Mar 22, 2012 at 7:59 AM, Pointbreak
>> <po...@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.
>
> 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...
> 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.
-igor
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Pointbreak <po...@ml1.net>.
On Thu, Mar 22, 2012, at 08:23, Igor Vaynberg wrote:
> On Thu, Mar 22, 2012 at 7:59 AM, Pointbreak
> <po...@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.
I have never had to build a website were it was a problem when the ajax
state was lost on page refresh. 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).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Igor Vaynberg <ig...@gmail.com>.
On Thu, Mar 22, 2012 at 7:59 AM, Pointbreak
<po...@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.
-igor
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Pointbreak <po...@ml1.net>.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Igor Vaynberg <ig...@gmail.com>.
On Tue, Mar 27, 2012 at 2:53 PM, armhold <ar...@gmail.com> wrote:
> Martin wrote:
>
>> HomePageMapper is explicitly registered in SystemMapper (the default
>> compound root mapper). The resource mapper example in
>> wicket-examples also mounts custom home mapper.
>
> Thanks Martin. I managed to get something working based on
> this. Here's a gist, in case anyone else is trying to get their home
> page mounted without the version query param:
> https://gist.github.com/2220564
>
> Mount it in WicketApplication like:
>
> getRootRequestMapperAsCompound().add(new NoVersionHomePageMapper());
>
> To be honest I'm not sure what it means to return a compatibilityScore
>> 0, which indicates "I can handle this request better than the
> HomePageMapper", but to then go and return null from mapRequest(). But
> that's what I had to do to get it to work. Cargo-cult programming for sure.
you are using maphandler() to generate the url to the homepage. a
higher compat score meaning that your handler's maphandler will be
used instead of the built in homepagemapper's. the method from a
handler with the highest score is used.
and returning null from maprequest() simply means "i cant map this
request", but thats ok because wicket's homepagemapper can and does.
so in essence your mapper can generate urls but not process them.
-igor
>
>
>
> --
> View this message in context: http://apache-wicket.1842946.n4.nabble.com/I-don-t-want-url-page-count-parameter-localhost-8080-context-0-tp4481510p4510319.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by armhold <ar...@gmail.com>.
Martin wrote:
> HomePageMapper is explicitly registered in SystemMapper (the default
> compound root mapper). The resource mapper example in
> wicket-examples also mounts custom home mapper.
Thanks Martin. I managed to get something working based on
this. Here's a gist, in case anyone else is trying to get their home
page mounted without the version query param:
https://gist.github.com/2220564
Mount it in WicketApplication like:
getRootRequestMapperAsCompound().add(new NoVersionHomePageMapper());
To be honest I'm not sure what it means to return a compatibilityScore
> 0, which indicates "I can handle this request better than the
HomePageMapper", but to then go and return null from mapRequest(). But
that's what I had to do to get it to work. Cargo-cult programming for sure.
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/I-don-t-want-url-page-count-parameter-localhost-8080-context-0-tp4481510p4510319.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Martin Grigorov <mg...@apache.org>.
On Mon, Mar 26, 2012 at 7:08 PM, armhold <ar...@gmail.com> wrote:
> I'm really grateful for this conversation, as I've been wondering the
> same question for a while now.
>
> Martin writes:
>
>> So far I didn't hear a good explanation why the page id causes you
>> troubles. Most of you are saying "it is ugly".
>
> Well it is kind of ugly. It is far less ugly than the 1.4-style
> "?wicket:interface=:1::::" URLs though. And after reading your and
> Igor's explanation, I understand better now why it's done this way, so
> thank you for that.
>
> As for why it causes troubles: I've done a handful of wicket projects
> for different clients in the past year, and I get asked about this by
> the project owners *every* *single* *time*.
>
> For projects where users log in, create accounts, etc, the
> stakeholders are generally willing to accept the URL param (though
> they grumble a little bit).
>
> But for projects where a significant portion of the app's
> functionality is exposed to "drive by" users, stakeholders won't
> typically compromise on the URL structure. Some of their concerns come
> down to simple aesthetics. But a common objection is "it's hurting our
> SEO". The stated SEO concerns are that:
>
> A. page request results in a 302
Use RenderStrategy#ONE_PASS_RENDER
> B. search engines don't like to index urls with query params (probably
> apocryphal, or at least no longer true)
> C. page analytics- you now need to normalize URLs against the "?N"
> param
>
> Some (perhaps all?) of the SEO issues might be addressable by link
> rel="canonical"; I haven't tested it yet against 1.5.
>
>> Case 3 is what the bots and not logged in users should see. Bots
>> don't use sessions so don't let them go in the stateful area of your
>> app.
>
> If I understand correctly, this means no Ajax components at all on
> "not logged in" pages. For a lot of sites that just plain won't
> work. Please correct me if I have misunderstood something.
Use Jolira's stateless Ajax components/behaviors.
>
> I have a 1.4 project whose migration to 1.5 has been on hold for a
> while, in part due to the URL changes we'll have to make. I'm weighing
> the benefits of this NoVersionMount that was proposed to see what
> potential side effects it might have. So far it looks like it will
> cause loss of Ajax state if the user reloads the page or hits the back
> button, but no different from what currently happens in 1.4. I think
> that's probably a reasonable tradeoff for some apps, as long as you're
> aware of it. One issue (raised elsewhere on this list recently) is how
> to use NoVersionMount with the home page, since it's not explicitly
> mounted in WicketApplication.
HomePageMapper is explicitly registered in SystemMapper (the default
compound root mapper).
The resource mapper example in wicket-examples also mounts custom home mapper.
>
>
> --
> View this message in context: http://apache-wicket.1842946.n4.nabble.com/I-don-t-want-url-page-count-parameter-localhost-8080-context-0-tp4481510p4506482.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by armhold <ar...@gmail.com>.
I'm really grateful for this conversation, as I've been wondering the
same question for a while now.
Martin writes:
> So far I didn't hear a good explanation why the page id causes you
> troubles. Most of you are saying "it is ugly".
Well it is kind of ugly. It is far less ugly than the 1.4-style
"?wicket:interface=:1::::" URLs though. And after reading your and
Igor's explanation, I understand better now why it's done this way, so
thank you for that.
As for why it causes troubles: I've done a handful of wicket projects
for different clients in the past year, and I get asked about this by
the project owners *every* *single* *time*.
For projects where users log in, create accounts, etc, the
stakeholders are generally willing to accept the URL param (though
they grumble a little bit).
But for projects where a significant portion of the app's
functionality is exposed to "drive by" users, stakeholders won't
typically compromise on the URL structure. Some of their concerns come
down to simple aesthetics. But a common objection is "it's hurting our
SEO". The stated SEO concerns are that:
A. page request results in a 302
B. search engines don't like to index urls with query params (probably
apocryphal, or at least no longer true)
C. page analytics- you now need to normalize URLs against the "?N"
param
Some (perhaps all?) of the SEO issues might be addressable by link
rel="canonical"; I haven't tested it yet against 1.5.
> Case 3 is what the bots and not logged in users should see. Bots
> don't use sessions so don't let them go in the stateful area of your
> app.
If I understand correctly, this means no Ajax components at all on
"not logged in" pages. For a lot of sites that just plain won't
work. Please correct me if I have misunderstood something.
I have a 1.4 project whose migration to 1.5 has been on hold for a
while, in part due to the URL changes we'll have to make. I'm weighing
the benefits of this NoVersionMount that was proposed to see what
potential side effects it might have. So far it looks like it will
cause loss of Ajax state if the user reloads the page or hits the back
button, but no different from what currently happens in 1.4. I think
that's probably a reasonable tradeoff for some apps, as long as you're
aware of it. One issue (raised elsewhere on this list recently) is how
to use NoVersionMount with the home page, since it's not explicitly
mounted in WicketApplication.
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/I-don-t-want-url-page-count-parameter-localhost-8080-context-0-tp4481510p4506482.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
So far I didn't hear a good explanation why the page id causes you
troubles. Most of you are saying "it is ugly". In my previous company
we asked some of our users about
"wicket:interface=0:1:Something:else:9" and most of them said "I don't
care", "I haven't noticed it", etc... And we did this just because one
of the technical managers was bothered by it. So it seems only
developers really care what is in the the address bar (and bots but
this will covered later).
So it is one of those:
1. stateful and "ugly"
2. stateful, pretty and broken
3. stateless and pretty
Case 1 is what Igor explained.
Case 2 is what Chris, pointbreak and Paolo seems to use in production.
See Igor's explanation why it is broken and why your users may loose
their state. So don't keep the shopping card (or any other state) in
the components!
Case 3 is what the bots and not logged in users should see. Bots don't
use sessions so don't let them go in the stateful area of your app.
They should see the list of products, not the list in their shopping
card, right ?
@Chris: about your example with previous page and previous state of
the shopping card: if you use dynamic models and page caching is
disabled then the page will show the components from the previous
version but their content will be the last available one. I.e. the
shopping card will show what it has to show.
On Mon, Mar 19, 2012 at 5:00 AM, Igor Vaynberg <ig...@gmail.com> wrote:
> On Sun, Mar 18, 2012 at 5:27 PM, Chris Colman
> <ch...@stepaheadsoftware.com> wrote:
>> I've been thinking about the new 1.5 page ID/versioning feature (which
>> we disabled as soon as we discovered it) and wondering if there is
>> actually a real world scenario for stateful pages that actually requires
>> this functionality.
>>
>> I understand the purpose is so that the browser's 'Back' function can
>> work "properly" (and maybe efficiently) but, in all the scenarios we
>> have at least, "proper" would be to re-render and not pull the page from
>> the cache.
>>
>> For example, an online store with the current shopping cart displayed in
>> the right hand column:
>>
>> Browser is showing page for product A, no products in shopping cart
>> shown in right column.
>>
>> User goes to page for product B, adds product B to shopping cart.
>>
>> Hit's back button.
>>
>> Now wouldn't the 'page versioning/id' feature now show the cached page
>> for product A with a shopping cart that is still empty even though the
>> user just added product B? Or would it realize that the shopping cart
>> panel's model has changed and update it to reflect the newly added item?
>>
>> In this scenario showing an empty shopping cart is a very definite
>> incorrect behavior that will freak out the user who believes that they
>> have added a product B (which they have) but it is not shown in the
>> shopping cart.
>>
>> 1.4 functionality (without page ID) worked fine. We never had a single
>> complaint about back button not displaying the correct result.
>
> 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
>
> now same with page versioning enabled and page caching disabled
>
> 1. wicket creates page and assigns it id 1
> 2. wicket clones page with id 1 into a new instance with id 2. id 1
> has panel A and id 2 has panel B
> 3. wicket renders page with id 1
> 4. wicket loads page with id 1, the link is executed
>
> now same with page versioning enabled and page caching enabled
>
> 1. wicket creates page and assigns it id 1
> 2. wicket clones page with id 1 into a new instance with id 2. id 1
> has panel A and id 2 has panel B
> 3. browser renders page from cache
> 4. wicket loads page with id 1 (page id is encoded in link's url), the
> link is executed
>
> in wicket 1.4 page id would not change but step 2 would increment the
> page's version. there would still be two instances of the page: id1
> version 1, id1 version 2
>
> now you may be referring to the fact that unlike in 1.4 in 1.5 we
> immediately redirect to a versioned url when a bookmarkable url is
> accessed....
>
> in 1.4 when user hits /mount they would stay on that url
> in 1.5 when user hits /mount they are redirected to /mount?2 where 2
> is the next available page id
>
> in 1.4 a lot of users complained that when the user access a
> bookmarkable page and uses ajax to navigate/change the state of the
> page all that state is lost when they refresh the page. this is
> because when they refresh the page the browser requests the same url
> (the bookmarkable one) and a new instance of the page is created. this
> is really frustrating to users of ajax-based applications.
>
> in 1.5 when the user navigates to a mount we immediately redirect to a
> statefull url of the new page instance. now when the user makes a
> bunch of changes via ajax and presses refresh the page is refreshed
> with those changes preserved.
>
> this is why 1.4 had hybrid url coding strategy, but because it wasnt
> the default it still had some usecases that didnt work correctly.
>
> since most applications use ajax we made this the default behavior of 1.5.
>
> -igor
>
>
>>
>> I'm half doubting whether page ID is a useful feature but half wondering
>> if it is a useful feature for which I just haven't discovered useful
>> scenarios where it is of benefit and so I should find these scenarios
>> and change my design to use it.
>>
>> Thoughts?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Igor Vaynberg <ig...@gmail.com>.
On Sun, Mar 18, 2012 at 5:27 PM, Chris Colman
<ch...@stepaheadsoftware.com> wrote:
> I've been thinking about the new 1.5 page ID/versioning feature (which
> we disabled as soon as we discovered it) and wondering if there is
> actually a real world scenario for stateful pages that actually requires
> this functionality.
>
> I understand the purpose is so that the browser's 'Back' function can
> work "properly" (and maybe efficiently) but, in all the scenarios we
> have at least, "proper" would be to re-render and not pull the page from
> the cache.
>
> For example, an online store with the current shopping cart displayed in
> the right hand column:
>
> Browser is showing page for product A, no products in shopping cart
> shown in right column.
>
> User goes to page for product B, adds product B to shopping cart.
>
> Hit's back button.
>
> Now wouldn't the 'page versioning/id' feature now show the cached page
> for product A with a shopping cart that is still empty even though the
> user just added product B? Or would it realize that the shopping cart
> panel's model has changed and update it to reflect the newly added item?
>
> In this scenario showing an empty shopping cart is a very definite
> incorrect behavior that will freak out the user who believes that they
> have added a product B (which they have) but it is not shown in the
> shopping cart.
>
> 1.4 functionality (without page ID) worked fine. We never had a single
> complaint about back button not displaying the correct result.
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
now same with page versioning enabled and page caching disabled
1. wicket creates page and assigns it id 1
2. wicket clones page with id 1 into a new instance with id 2. id 1
has panel A and id 2 has panel B
3. wicket renders page with id 1
4. wicket loads page with id 1, the link is executed
now same with page versioning enabled and page caching enabled
1. wicket creates page and assigns it id 1
2. wicket clones page with id 1 into a new instance with id 2. id 1
has panel A and id 2 has panel B
3. browser renders page from cache
4. wicket loads page with id 1 (page id is encoded in link's url), the
link is executed
in wicket 1.4 page id would not change but step 2 would increment the
page's version. there would still be two instances of the page: id1
version 1, id1 version 2
now you may be referring to the fact that unlike in 1.4 in 1.5 we
immediately redirect to a versioned url when a bookmarkable url is
accessed....
in 1.4 when user hits /mount they would stay on that url
in 1.5 when user hits /mount they are redirected to /mount?2 where 2
is the next available page id
in 1.4 a lot of users complained that when the user access a
bookmarkable page and uses ajax to navigate/change the state of the
page all that state is lost when they refresh the page. this is
because when they refresh the page the browser requests the same url
(the bookmarkable one) and a new instance of the page is created. this
is really frustrating to users of ajax-based applications.
in 1.5 when the user navigates to a mount we immediately redirect to a
statefull url of the new page instance. now when the user makes a
bunch of changes via ajax and presses refresh the page is refreshed
with those changes preserved.
this is why 1.4 had hybrid url coding strategy, but because it wasnt
the default it still had some usecases that didnt work correctly.
since most applications use ajax we made this the default behavior of 1.5.
-igor
>
> I'm half doubting whether page ID is a useful feature but half wondering
> if it is a useful feature for which I just haven't discovered useful
> scenarios where it is of benefit and so I should find these scenarios
> and change my design to use it.
>
> Thoughts?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: What real life scenario calls for page ID?
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
>-----Original Message-----
>From: Paolo [mailto:irresistiblecam@gmail.com]
>> Thoughts?
>I support you!
>I implemented class NoVersionMount thanks to pointbreak in my
>MainApplication.
>And It will be my template for future app.
>But to do it, I needed to understood the problem, check on google, read
a
>lot of pages,
>without found a solution, so post the question here, and after 3 post,
got
>a right reply for me.
>Why an wicket user have to do all this????
>Why not, wicket use the NoVersionMount as default Mount? Like in wicket
>1.4 and implement an VersionMount as an alternative for developer?
I agree. It sounds like it might be useful for some scenarios (but none
that I have discovered yet) but for most it seems like the 1.4 default
works perfectly well.
Maybe the NoVersionMount should be the default and if some developers
have found a scenario that requires versioned pages they can turn it on
somehow.
Or, at least make the 1.4 default a 'configurable' option rather than
have to implement a class to set up something which seems like a much
more common requirement.
>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by MattyDE <uf...@gmail.com>.
I really enjoyed reading this conversation. But still one question is open
for me right know:
How should i able to test my site effectively (while developing) when F5
always shows the oldstate (also when the tomcat has been restarted) ... is
there any workaround to disable this "Behavoir" for the dev-phase?
Thanks in Advance :)
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/I-don-t-want-url-page-count-parameter-localhost-8080-context-0-tp4481510p4653384.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Bertrand Guay-Paquet <be...@step.polymtl.ca>.
I reproduced the issue in the quickstart attached to WICKET-4488.
On 04/04/2012 3:44 PM, Martin Grigorov wrote:
> Hi Bertrand,
>
> Did you verify that ? If yes and you have a quickstart then create a ticket.
> There are no tickets from this discussion so far.
>
> On Wed, Apr 4, 2012 at 6:31 PM, Bertrand Guay-Paquet
> <be...@step.polymtl.ca> wrote:
>> Hi,
>>
>> Is there a JIRA issue tracking this "render wrong page based on page
>> version" problem? I'm very interested in this issue since sharing links to
>> stateful pages containing a page version is essentially broken.
>>
>> Regards,
>> Bertrand
>>
>>
>> On 20/03/2012 12:45 PM, Igor Vaynberg wrote:
>>> On Tue, Mar 20, 2012 at 8:52 AM, Martin Grigorov<mg...@apache.org>
>>> wrote:
>>>> On Tue, Mar 20, 2012 at 5:42 PM, Igor Vaynberg<ig...@gmail.com>
>>>> wrote:
>>>>> On Tue, Mar 20, 2012 at 8:28 AM, Martin Grigorov<mg...@apache.org>
>>>>> wrote:
>>>>>> On Tue, Mar 20, 2012 at 5:20 PM, Igor Vaynberg<ig...@gmail.com>
>>>>>> wrote:
>>>>>>> On Tue, Mar 20, 2012 at 1:07 AM, Martin Grigorov<mg...@apache.org>
>>>>>>> wrote:
>>>>>>>> On Tue, Mar 20, 2012 at 12:55 AM, Igor
>>>>>>>> Vaynberg<ig...@gmail.com> wrote:
>>>>>>>>> indeed. we should check that the page pointed to by the id maps back
>>>>>>>>> to the mount, and create a new instance based on the mount if it
>>>>>>>>> doesnt. jira please.
>>>>>>>> This is already the case, no need of a ticket for this. If there is
>>>>>>>> no
>>>>>>>> ?5 then Wicket creates ?0 and shows it.
>>>>>>> this is not what i was talking about...
>>>>>>>
>>>>>>>> The "problem" Pointbreak actually mean is that userA may have opened
>>>>>>>> ?5 in his session, copy the url and give it to
>>>>>>>> userB, but userB also already have its own session and by chance he
>>>>>>>> also had reached ?5 and these two ?5s are
>>>>>>>> different because they may have different states for both users.
>>>>>>> not only are ?5 different, but they are entirely different pages.
>>>>>>>
>>>>>>> so user A goes to /foo, we redirect to /foo?0, they click around and
>>>>>>> end up on /foo?2
>>>>>>> user B goes to /bar, we redirect to /bar?0, they click around and end
>>>>>>> up on /bar?7
>>>>>>>
>>>>>>> now user A emails user B the /foo?2 link. when user B hits that link
>>>>>>> they end up going to a previous version of their *bar* page instead of
>>>>>>> some instance of /foo because we do not check the mount vs the page
>>>>>>> id, and whats worse we keep the mount in the url even though we are
>>>>>>> displaying a page that is not mounted.
>>>>>> Ouch!
>>>>>>
>>>>>>> i guess this is why in 1.4 we dropped the mount from nonbookmarkable
>>>>>>> urls...
>>>>>> I hope you don't mean that we have to redirect to wicket/page?0 from
>>>>>> the bookmarkable url that the user requested.
>>>>> no. we should redirect to wicket/page?x when the user navigates away
>>>>> from the mounted page.
>>>>>
>>>>> so i go to /bar which is BarPage and end up on /bar?0. click a link
>>>>> that does something to BarPage, so end up on /bar?1. click a link that
>>>>> takes me to FooPage, at this point since the page does not match the
>>>>> mount i should go to /wicket/page?3
>>>> Currently it works just as you described it. Or I don't understand you
>>>> well.
>>>> A quickstart will make it more clear :-)
>>>>
>>>> My "ouch" was for something else - userA sends foo?5, but userB's ?5
>>>> is for BarPage and current PageProvider will silently return BarPage's
>>>> version5. It wont be FooPage!
>>> hrm. yes. in a cleanroom quickstart that is indeed how it works. in
>>> our prod app, for some reason, it just shows the other page on the old
>>> page's mount. i will have to dig into that in our code base.
>>>
>>> the quickstart does show what you have described above (showing the
>>> old version of the page instead of creating a new one), but it also
>>> does another interesting. when it redirects to the incorrect version
>>> of the other page it also uses wicket/bookmarkable url instead of the
>>> mount.
>>>
>>> so when i am on /bar?4 and change 4 to 2 which is a version of FooPage
>>> mounted on /foo i dont go to /foo?5 like i should, instead i go to
>>> /wicket/bookmarkable/FooPage?2
>>>
>>> -igor
>>>
>>>
>>>
>>>>> -igor
>>>>>
>>>>>> It'd be better if we check the type of the stored page against the
>>>>>> type of the page that is mounted at this "bookmarkable" url and throw
>>>>>> PageExpiredException if they don't match.
>>>>>>
>>>>>>> -igor
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> The confusing part here is "bookmarkable". Now imagine that there is
>>>>>>>> no ?pageId in the url. userA clicks several Ajax links to get to
>>>>>>>> version5 of that page and then copy/paste the url but userB will see
>>>>>>>> the initial state of the page, not version5 that userA actually
>>>>>>>> meant.
>>>>>>>> So it seems only ?0 is actually "bookmarkable" for stateful pages.
>>>>>>>> Only in this case both users will see the same content (if there is
>>>>>>>> no
>>>>>>>> special logic for user permissions involved).
>>>>>>>>
>>>>>>>> If userA wants to fully share his page with userB then he has to
>>>>>>>> share
>>>>>>>> his session too, i.e. both ?5 and jessionid= has to be in the pasted
>>>>>>>> url. I don't recomment this!
>>>>>>>>
>>>>>>>> ?5 helps when the user refreshes the page in his current session. In
>>>>>>>> this case he will see the same content as before the refresh. In 1.4
>>>>>>>> he'd see the initial state of the page and will loose any state that
>>>>>>>> is not persisted so far.
>>>>>>>>
>>>>>>>>
>>>>>>>>> -igor
>>>>>>>>>
>>>>>>>>> On Mon, Mar 19, 2012 at 3:52 PM, Pointbreak
>>>>>>>>> <po...@ml1.net> wrote:
>>>>>>>>>> It's a problem when users bookmark it. Because ...?5 this session
>>>>>>>>>> is an
>>>>>>>>>> entirely other page as ...?5 in another session tomorrow.
>>>>>>>>>>
>>>>>>>>>> On Mon, Mar 19, 2012, at 11:53, Girts Ziemelis wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 2012-03-19 02:46, Paolo wrote:
>>>>>>>>>>>> I support you! I implemented class NoVersionMount thanks to
>>>>>>>>>>>> pointbreak
>>>>>>>>>>>> in my MainApplication. And It will be my template for future app.
>>>>>>>>>>>> But
>>>>>>>>>>>> to do it, I needed to understood the problem, check on google,
>>>>>>>>>>>> read a
>>>>>>>>>>>> lot of pages, without found a solution, so post the question
>>>>>>>>>>>> here, and
>>>>>>>>>>>> after 3 post, got a right reply for me. Why an wicket user have
>>>>>>>>>>>> to do
>>>>>>>>>>>> all this???? Why not, wicket use the NoVersionMount as default
>>>>>>>>>>>> Mount?
>>>>>>>>>>>> Like in wicket 1.4. And implement an VersionMount as an
>>>>>>>>>>>> alternative
>>>>>>>>>>>> for developer?
>>>>>>>>>>> I actually like this change so far. I can finally tell, that my
>>>>>>>>>>> page is
>>>>>>>>>>> stetefull just by looking at the link and ask myself question - if
>>>>>>>>>>> I
>>>>>>>>>>> really care so much about the clean link for this page, may be it
>>>>>>>>>>> should
>>>>>>>>>>> be stateless in a first place?
>>>>>>>>>>>
>>>>>>>>>>> And why is ?0 such a big problem? It does not cause problems
>>>>>>>>>>> sending
>>>>>>>>>>> links.
>>>>>>>>>>> Is there any real proof of google indexing problems so far?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Martin Grigorov
>>>>>>>> jWeekend
>>>>>>>> Training, Consulting, Development
>>>>>>>> http://jWeekend.com
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Martin Grigorov
>>>>>> jWeekend
>>>>>> Training, Consulting, Development
>>>>>> http://jWeekend.com
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>
>>>> --
>>>> Martin Grigorov
>>>> jWeekend
>>>> Training, Consulting, Development
>>>> http://jWeekend.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Martin Grigorov <mg...@apache.org>.
Hi Bertrand,
Did you verify that ? If yes and you have a quickstart then create a ticket.
There are no tickets from this discussion so far.
On Wed, Apr 4, 2012 at 6:31 PM, Bertrand Guay-Paquet
<be...@step.polymtl.ca> wrote:
> Hi,
>
> Is there a JIRA issue tracking this "render wrong page based on page
> version" problem? I'm very interested in this issue since sharing links to
> stateful pages containing a page version is essentially broken.
>
> Regards,
> Bertrand
>
>
> On 20/03/2012 12:45 PM, Igor Vaynberg wrote:
>>
>> On Tue, Mar 20, 2012 at 8:52 AM, Martin Grigorov<mg...@apache.org>
>> wrote:
>>>
>>> On Tue, Mar 20, 2012 at 5:42 PM, Igor Vaynberg<ig...@gmail.com>
>>> wrote:
>>>>
>>>> On Tue, Mar 20, 2012 at 8:28 AM, Martin Grigorov<mg...@apache.org>
>>>> wrote:
>>>>>
>>>>> On Tue, Mar 20, 2012 at 5:20 PM, Igor Vaynberg<ig...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> On Tue, Mar 20, 2012 at 1:07 AM, Martin Grigorov<mg...@apache.org>
>>>>>> wrote:
>>>>>>>
>>>>>>> On Tue, Mar 20, 2012 at 12:55 AM, Igor
>>>>>>> Vaynberg<ig...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> indeed. we should check that the page pointed to by the id maps back
>>>>>>>> to the mount, and create a new instance based on the mount if it
>>>>>>>> doesnt. jira please.
>>>>>>>
>>>>>>> This is already the case, no need of a ticket for this. If there is
>>>>>>> no
>>>>>>> ?5 then Wicket creates ?0 and shows it.
>>>>>>
>>>>>> this is not what i was talking about...
>>>>>>
>>>>>>> The "problem" Pointbreak actually mean is that userA may have opened
>>>>>>> ?5 in his session, copy the url and give it to
>>>>>>> userB, but userB also already have its own session and by chance he
>>>>>>> also had reached ?5 and these two ?5s are
>>>>>>> different because they may have different states for both users.
>>>>>>
>>>>>> not only are ?5 different, but they are entirely different pages.
>>>>>>
>>>>>> so user A goes to /foo, we redirect to /foo?0, they click around and
>>>>>> end up on /foo?2
>>>>>> user B goes to /bar, we redirect to /bar?0, they click around and end
>>>>>> up on /bar?7
>>>>>>
>>>>>> now user A emails user B the /foo?2 link. when user B hits that link
>>>>>> they end up going to a previous version of their *bar* page instead of
>>>>>> some instance of /foo because we do not check the mount vs the page
>>>>>> id, and whats worse we keep the mount in the url even though we are
>>>>>> displaying a page that is not mounted.
>>>>>
>>>>> Ouch!
>>>>>
>>>>>> i guess this is why in 1.4 we dropped the mount from nonbookmarkable
>>>>>> urls...
>>>>>
>>>>> I hope you don't mean that we have to redirect to wicket/page?0 from
>>>>> the bookmarkable url that the user requested.
>>>>
>>>> no. we should redirect to wicket/page?x when the user navigates away
>>>> from the mounted page.
>>>>
>>>> so i go to /bar which is BarPage and end up on /bar?0. click a link
>>>> that does something to BarPage, so end up on /bar?1. click a link that
>>>> takes me to FooPage, at this point since the page does not match the
>>>> mount i should go to /wicket/page?3
>>>
>>> Currently it works just as you described it. Or I don't understand you
>>> well.
>>> A quickstart will make it more clear :-)
>>>
>>> My "ouch" was for something else - userA sends foo?5, but userB's ?5
>>> is for BarPage and current PageProvider will silently return BarPage's
>>> version5. It wont be FooPage!
>>
>> hrm. yes. in a cleanroom quickstart that is indeed how it works. in
>> our prod app, for some reason, it just shows the other page on the old
>> page's mount. i will have to dig into that in our code base.
>>
>> the quickstart does show what you have described above (showing the
>> old version of the page instead of creating a new one), but it also
>> does another interesting. when it redirects to the incorrect version
>> of the other page it also uses wicket/bookmarkable url instead of the
>> mount.
>>
>> so when i am on /bar?4 and change 4 to 2 which is a version of FooPage
>> mounted on /foo i dont go to /foo?5 like i should, instead i go to
>> /wicket/bookmarkable/FooPage?2
>>
>> -igor
>>
>>
>>
>>>> -igor
>>>>
>>>>> It'd be better if we check the type of the stored page against the
>>>>> type of the page that is mounted at this "bookmarkable" url and throw
>>>>> PageExpiredException if they don't match.
>>>>>
>>>>>> -igor
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> The confusing part here is "bookmarkable". Now imagine that there is
>>>>>>> no ?pageId in the url. userA clicks several Ajax links to get to
>>>>>>> version5 of that page and then copy/paste the url but userB will see
>>>>>>> the initial state of the page, not version5 that userA actually
>>>>>>> meant.
>>>>>>> So it seems only ?0 is actually "bookmarkable" for stateful pages.
>>>>>>> Only in this case both users will see the same content (if there is
>>>>>>> no
>>>>>>> special logic for user permissions involved).
>>>>>>>
>>>>>>> If userA wants to fully share his page with userB then he has to
>>>>>>> share
>>>>>>> his session too, i.e. both ?5 and jessionid= has to be in the pasted
>>>>>>> url. I don't recomment this!
>>>>>>>
>>>>>>> ?5 helps when the user refreshes the page in his current session. In
>>>>>>> this case he will see the same content as before the refresh. In 1.4
>>>>>>> he'd see the initial state of the page and will loose any state that
>>>>>>> is not persisted so far.
>>>>>>>
>>>>>>>
>>>>>>>> -igor
>>>>>>>>
>>>>>>>> On Mon, Mar 19, 2012 at 3:52 PM, Pointbreak
>>>>>>>> <po...@ml1.net> wrote:
>>>>>>>>>
>>>>>>>>> It's a problem when users bookmark it. Because ...?5 this session
>>>>>>>>> is an
>>>>>>>>> entirely other page as ...?5 in another session tomorrow.
>>>>>>>>>
>>>>>>>>> On Mon, Mar 19, 2012, at 11:53, Girts Ziemelis wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 2012-03-19 02:46, Paolo wrote:
>>>>>>>>>>>
>>>>>>>>>>> I support you! I implemented class NoVersionMount thanks to
>>>>>>>>>>> pointbreak
>>>>>>>>>>> in my MainApplication. And It will be my template for future app.
>>>>>>>>>>> But
>>>>>>>>>>> to do it, I needed to understood the problem, check on google,
>>>>>>>>>>> read a
>>>>>>>>>>> lot of pages, without found a solution, so post the question
>>>>>>>>>>> here, and
>>>>>>>>>>> after 3 post, got a right reply for me. Why an wicket user have
>>>>>>>>>>> to do
>>>>>>>>>>> all this???? Why not, wicket use the NoVersionMount as default
>>>>>>>>>>> Mount?
>>>>>>>>>>> Like in wicket 1.4. And implement an VersionMount as an
>>>>>>>>>>> alternative
>>>>>>>>>>> for developer?
>>>>>>>>>>
>>>>>>>>>> I actually like this change so far. I can finally tell, that my
>>>>>>>>>> page is
>>>>>>>>>> stetefull just by looking at the link and ask myself question - if
>>>>>>>>>> I
>>>>>>>>>> really care so much about the clean link for this page, may be it
>>>>>>>>>> should
>>>>>>>>>> be stateless in a first place?
>>>>>>>>>>
>>>>>>>>>> And why is ?0 such a big problem? It does not cause problems
>>>>>>>>>> sending
>>>>>>>>>> links.
>>>>>>>>>> Is there any real proof of google indexing problems so far?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Martin Grigorov
>>>>>>> jWeekend
>>>>>>> Training, Consulting, Development
>>>>>>> http://jWeekend.com
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Martin Grigorov
>>>>> jWeekend
>>>>> Training, Consulting, Development
>>>>> http://jWeekend.com
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>
>>>
>>> --
>>> Martin Grigorov
>>> jWeekend
>>> Training, Consulting, Development
>>> http://jWeekend.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Bertrand Guay-Paquet <be...@step.polymtl.ca>.
Hi,
Is there a JIRA issue tracking this "render wrong page based on page
version" problem? I'm very interested in this issue since sharing links
to stateful pages containing a page version is essentially broken.
Regards,
Bertrand
On 20/03/2012 12:45 PM, Igor Vaynberg wrote:
> On Tue, Mar 20, 2012 at 8:52 AM, Martin Grigorov<mg...@apache.org> wrote:
>> On Tue, Mar 20, 2012 at 5:42 PM, Igor Vaynberg<ig...@gmail.com> wrote:
>>> On Tue, Mar 20, 2012 at 8:28 AM, Martin Grigorov<mg...@apache.org> wrote:
>>>> On Tue, Mar 20, 2012 at 5:20 PM, Igor Vaynberg<ig...@gmail.com> wrote:
>>>>> On Tue, Mar 20, 2012 at 1:07 AM, Martin Grigorov<mg...@apache.org> wrote:
>>>>>> On Tue, Mar 20, 2012 at 12:55 AM, Igor Vaynberg<ig...@gmail.com> wrote:
>>>>>>> indeed. we should check that the page pointed to by the id maps back
>>>>>>> to the mount, and create a new instance based on the mount if it
>>>>>>> doesnt. jira please.
>>>>>> This is already the case, no need of a ticket for this. If there is no
>>>>>> ?5 then Wicket creates ?0 and shows it.
>>>>> this is not what i was talking about...
>>>>>
>>>>>> The "problem" Pointbreak actually mean is that userA may have opened
>>>>>> ?5 in his session, copy the url and give it to
>>>>>> userB, but userB also already have its own session and by chance he
>>>>>> also had reached ?5 and these two ?5s are
>>>>>> different because they may have different states for both users.
>>>>> not only are ?5 different, but they are entirely different pages.
>>>>>
>>>>> so user A goes to /foo, we redirect to /foo?0, they click around and
>>>>> end up on /foo?2
>>>>> user B goes to /bar, we redirect to /bar?0, they click around and end
>>>>> up on /bar?7
>>>>>
>>>>> now user A emails user B the /foo?2 link. when user B hits that link
>>>>> they end up going to a previous version of their *bar* page instead of
>>>>> some instance of /foo because we do not check the mount vs the page
>>>>> id, and whats worse we keep the mount in the url even though we are
>>>>> displaying a page that is not mounted.
>>>> Ouch!
>>>>
>>>>> i guess this is why in 1.4 we dropped the mount from nonbookmarkable urls...
>>>> I hope you don't mean that we have to redirect to wicket/page?0 from
>>>> the bookmarkable url that the user requested.
>>> no. we should redirect to wicket/page?x when the user navigates away
>>> from the mounted page.
>>>
>>> so i go to /bar which is BarPage and end up on /bar?0. click a link
>>> that does something to BarPage, so end up on /bar?1. click a link that
>>> takes me to FooPage, at this point since the page does not match the
>>> mount i should go to /wicket/page?3
>> Currently it works just as you described it. Or I don't understand you well.
>> A quickstart will make it more clear :-)
>>
>> My "ouch" was for something else - userA sends foo?5, but userB's ?5
>> is for BarPage and current PageProvider will silently return BarPage's
>> version5. It wont be FooPage!
> hrm. yes. in a cleanroom quickstart that is indeed how it works. in
> our prod app, for some reason, it just shows the other page on the old
> page's mount. i will have to dig into that in our code base.
>
> the quickstart does show what you have described above (showing the
> old version of the page instead of creating a new one), but it also
> does another interesting. when it redirects to the incorrect version
> of the other page it also uses wicket/bookmarkable url instead of the
> mount.
>
> so when i am on /bar?4 and change 4 to 2 which is a version of FooPage
> mounted on /foo i dont go to /foo?5 like i should, instead i go to
> /wicket/bookmarkable/FooPage?2
>
> -igor
>
>
>
>>> -igor
>>>
>>>> It'd be better if we check the type of the stored page against the
>>>> type of the page that is mounted at this "bookmarkable" url and throw
>>>> PageExpiredException if they don't match.
>>>>
>>>>> -igor
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> The confusing part here is "bookmarkable". Now imagine that there is
>>>>>> no ?pageId in the url. userA clicks several Ajax links to get to
>>>>>> version5 of that page and then copy/paste the url but userB will see
>>>>>> the initial state of the page, not version5 that userA actually meant.
>>>>>> So it seems only ?0 is actually "bookmarkable" for stateful pages.
>>>>>> Only in this case both users will see the same content (if there is no
>>>>>> special logic for user permissions involved).
>>>>>>
>>>>>> If userA wants to fully share his page with userB then he has to share
>>>>>> his session too, i.e. both ?5 and jessionid= has to be in the pasted
>>>>>> url. I don't recomment this!
>>>>>>
>>>>>> ?5 helps when the user refreshes the page in his current session. In
>>>>>> this case he will see the same content as before the refresh. In 1.4
>>>>>> he'd see the initial state of the page and will loose any state that
>>>>>> is not persisted so far.
>>>>>>
>>>>>>
>>>>>>> -igor
>>>>>>>
>>>>>>> On Mon, Mar 19, 2012 at 3:52 PM, Pointbreak
>>>>>>> <po...@ml1.net> wrote:
>>>>>>>> It's a problem when users bookmark it. Because ...?5 this session is an
>>>>>>>> entirely other page as ...?5 in another session tomorrow.
>>>>>>>>
>>>>>>>> On Mon, Mar 19, 2012, at 11:53, Girts Ziemelis wrote:
>>>>>>>>>
>>>>>>>>> On 2012-03-19 02:46, Paolo wrote:
>>>>>>>>>> I support you! I implemented class NoVersionMount thanks to pointbreak
>>>>>>>>>> in my MainApplication. And It will be my template for future app. But
>>>>>>>>>> to do it, I needed to understood the problem, check on google, read a
>>>>>>>>>> lot of pages, without found a solution, so post the question here, and
>>>>>>>>>> after 3 post, got a right reply for me. Why an wicket user have to do
>>>>>>>>>> all this???? Why not, wicket use the NoVersionMount as default Mount?
>>>>>>>>>> Like in wicket 1.4. And implement an VersionMount as an alternative
>>>>>>>>>> for developer?
>>>>>>>>> I actually like this change so far. I can finally tell, that my page is
>>>>>>>>> stetefull just by looking at the link and ask myself question - if I
>>>>>>>>> really care so much about the clean link for this page, may be it should
>>>>>>>>> be stateless in a first place?
>>>>>>>>>
>>>>>>>>> And why is ?0 such a big problem? It does not cause problems sending
>>>>>>>>> links.
>>>>>>>>> Is there any real proof of google indexing problems so far?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Martin Grigorov
>>>>>> jWeekend
>>>>>> Training, Consulting, Development
>>>>>> http://jWeekend.com
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>
>>>>
>>>> --
>>>> Martin Grigorov
>>>> jWeekend
>>>> Training, Consulting, Development
>>>> http://jWeekend.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Igor Vaynberg <ig...@gmail.com>.
On Tue, Mar 20, 2012 at 8:52 AM, Martin Grigorov <mg...@apache.org> wrote:
> On Tue, Mar 20, 2012 at 5:42 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>> On Tue, Mar 20, 2012 at 8:28 AM, Martin Grigorov <mg...@apache.org> wrote:
>>> On Tue, Mar 20, 2012 at 5:20 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>>>> On Tue, Mar 20, 2012 at 1:07 AM, Martin Grigorov <mg...@apache.org> wrote:
>>>>> On Tue, Mar 20, 2012 at 12:55 AM, Igor Vaynberg <ig...@gmail.com> wrote:
>>>>>> indeed. we should check that the page pointed to by the id maps back
>>>>>> to the mount, and create a new instance based on the mount if it
>>>>>> doesnt. jira please.
>>>>>
>>>>> This is already the case, no need of a ticket for this. If there is no
>>>>> ?5 then Wicket creates ?0 and shows it.
>>>>
>>>> this is not what i was talking about...
>>>>
>>>>> The "problem" Pointbreak actually mean is that userA may have opened
>>>>> ?5 in his session, copy the url and give it to
>>>>> userB, but userB also already have its own session and by chance he
>>>>> also had reached ?5 and these two ?5s are
>>>>> different because they may have different states for both users.
>>>>
>>>> not only are ?5 different, but they are entirely different pages.
>>>>
>>>> so user A goes to /foo, we redirect to /foo?0, they click around and
>>>> end up on /foo?2
>>>> user B goes to /bar, we redirect to /bar?0, they click around and end
>>>> up on /bar?7
>>>>
>>>> now user A emails user B the /foo?2 link. when user B hits that link
>>>> they end up going to a previous version of their *bar* page instead of
>>>> some instance of /foo because we do not check the mount vs the page
>>>> id, and whats worse we keep the mount in the url even though we are
>>>> displaying a page that is not mounted.
>>>
>>> Ouch!
>>>
>>>>
>>>> i guess this is why in 1.4 we dropped the mount from nonbookmarkable urls...
>>>
>>> I hope you don't mean that we have to redirect to wicket/page?0 from
>>> the bookmarkable url that the user requested.
>>
>> no. we should redirect to wicket/page?x when the user navigates away
>> from the mounted page.
>>
>> so i go to /bar which is BarPage and end up on /bar?0. click a link
>> that does something to BarPage, so end up on /bar?1. click a link that
>> takes me to FooPage, at this point since the page does not match the
>> mount i should go to /wicket/page?3
>
> Currently it works just as you described it. Or I don't understand you well.
> A quickstart will make it more clear :-)
>
> My "ouch" was for something else - userA sends foo?5, but userB's ?5
> is for BarPage and current PageProvider will silently return BarPage's
> version5. It wont be FooPage!
hrm. yes. in a cleanroom quickstart that is indeed how it works. in
our prod app, for some reason, it just shows the other page on the old
page's mount. i will have to dig into that in our code base.
the quickstart does show what you have described above (showing the
old version of the page instead of creating a new one), but it also
does another interesting. when it redirects to the incorrect version
of the other page it also uses wicket/bookmarkable url instead of the
mount.
so when i am on /bar?4 and change 4 to 2 which is a version of FooPage
mounted on /foo i dont go to /foo?5 like i should, instead i go to
/wicket/bookmarkable/FooPage?2
-igor
>
>>
>> -igor
>>
>>> It'd be better if we check the type of the stored page against the
>>> type of the page that is mounted at this "bookmarkable" url and throw
>>> PageExpiredException if they don't match.
>>>
>>>>
>>>> -igor
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> The confusing part here is "bookmarkable". Now imagine that there is
>>>>> no ?pageId in the url. userA clicks several Ajax links to get to
>>>>> version5 of that page and then copy/paste the url but userB will see
>>>>> the initial state of the page, not version5 that userA actually meant.
>>>>> So it seems only ?0 is actually "bookmarkable" for stateful pages.
>>>>> Only in this case both users will see the same content (if there is no
>>>>> special logic for user permissions involved).
>>>>>
>>>>> If userA wants to fully share his page with userB then he has to share
>>>>> his session too, i.e. both ?5 and jessionid= has to be in the pasted
>>>>> url. I don't recomment this!
>>>>>
>>>>> ?5 helps when the user refreshes the page in his current session. In
>>>>> this case he will see the same content as before the refresh. In 1.4
>>>>> he'd see the initial state of the page and will loose any state that
>>>>> is not persisted so far.
>>>>>
>>>>>
>>>>>>
>>>>>> -igor
>>>>>>
>>>>>> On Mon, Mar 19, 2012 at 3:52 PM, Pointbreak
>>>>>> <po...@ml1.net> wrote:
>>>>>>> It's a problem when users bookmark it. Because ...?5 this session is an
>>>>>>> entirely other page as ...?5 in another session tomorrow.
>>>>>>>
>>>>>>> On Mon, Mar 19, 2012, at 11:53, Girts Ziemelis wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2012-03-19 02:46, Paolo wrote:
>>>>>>>> > I support you! I implemented class NoVersionMount thanks to pointbreak
>>>>>>>> > in my MainApplication. And It will be my template for future app. But
>>>>>>>> > to do it, I needed to understood the problem, check on google, read a
>>>>>>>> > lot of pages, without found a solution, so post the question here, and
>>>>>>>> > after 3 post, got a right reply for me. Why an wicket user have to do
>>>>>>>> > all this???? Why not, wicket use the NoVersionMount as default Mount?
>>>>>>>> > Like in wicket 1.4. And implement an VersionMount as an alternative
>>>>>>>> > for developer?
>>>>>>>> I actually like this change so far. I can finally tell, that my page is
>>>>>>>> stetefull just by looking at the link and ask myself question - if I
>>>>>>>> really care so much about the clean link for this page, may be it should
>>>>>>>> be stateless in a first place?
>>>>>>>>
>>>>>>>> And why is ?0 such a big problem? It does not cause problems sending
>>>>>>>> links.
>>>>>>>> Is there any real proof of google indexing problems so far?
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Martin Grigorov
>>>>> jWeekend
>>>>> Training, Consulting, Development
>>>>> http://jWeekend.com
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Martin Grigorov
>>> jWeekend
>>> Training, Consulting, Development
>>> http://jWeekend.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Martin Grigorov <mg...@apache.org>.
On Tue, Mar 20, 2012 at 5:42 PM, Igor Vaynberg <ig...@gmail.com> wrote:
> On Tue, Mar 20, 2012 at 8:28 AM, Martin Grigorov <mg...@apache.org> wrote:
>> On Tue, Mar 20, 2012 at 5:20 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>>> On Tue, Mar 20, 2012 at 1:07 AM, Martin Grigorov <mg...@apache.org> wrote:
>>>> On Tue, Mar 20, 2012 at 12:55 AM, Igor Vaynberg <ig...@gmail.com> wrote:
>>>>> indeed. we should check that the page pointed to by the id maps back
>>>>> to the mount, and create a new instance based on the mount if it
>>>>> doesnt. jira please.
>>>>
>>>> This is already the case, no need of a ticket for this. If there is no
>>>> ?5 then Wicket creates ?0 and shows it.
>>>
>>> this is not what i was talking about...
>>>
>>>> The "problem" Pointbreak actually mean is that userA may have opened
>>>> ?5 in his session, copy the url and give it to
>>>> userB, but userB also already have its own session and by chance he
>>>> also had reached ?5 and these two ?5s are
>>>> different because they may have different states for both users.
>>>
>>> not only are ?5 different, but they are entirely different pages.
>>>
>>> so user A goes to /foo, we redirect to /foo?0, they click around and
>>> end up on /foo?2
>>> user B goes to /bar, we redirect to /bar?0, they click around and end
>>> up on /bar?7
>>>
>>> now user A emails user B the /foo?2 link. when user B hits that link
>>> they end up going to a previous version of their *bar* page instead of
>>> some instance of /foo because we do not check the mount vs the page
>>> id, and whats worse we keep the mount in the url even though we are
>>> displaying a page that is not mounted.
>>
>> Ouch!
>>
>>>
>>> i guess this is why in 1.4 we dropped the mount from nonbookmarkable urls...
>>
>> I hope you don't mean that we have to redirect to wicket/page?0 from
>> the bookmarkable url that the user requested.
>
> no. we should redirect to wicket/page?x when the user navigates away
> from the mounted page.
>
> so i go to /bar which is BarPage and end up on /bar?0. click a link
> that does something to BarPage, so end up on /bar?1. click a link that
> takes me to FooPage, at this point since the page does not match the
> mount i should go to /wicket/page?3
Currently it works just as you described it. Or I don't understand you well.
A quickstart will make it more clear :-)
My "ouch" was for something else - userA sends foo?5, but userB's ?5
is for BarPage and current PageProvider will silently return BarPage's
version5. It wont be FooPage!
>
> -igor
>
>> It'd be better if we check the type of the stored page against the
>> type of the page that is mounted at this "bookmarkable" url and throw
>> PageExpiredException if they don't match.
>>
>>>
>>> -igor
>>>
>>>
>>>
>>>
>>>>
>>>> The confusing part here is "bookmarkable". Now imagine that there is
>>>> no ?pageId in the url. userA clicks several Ajax links to get to
>>>> version5 of that page and then copy/paste the url but userB will see
>>>> the initial state of the page, not version5 that userA actually meant.
>>>> So it seems only ?0 is actually "bookmarkable" for stateful pages.
>>>> Only in this case both users will see the same content (if there is no
>>>> special logic for user permissions involved).
>>>>
>>>> If userA wants to fully share his page with userB then he has to share
>>>> his session too, i.e. both ?5 and jessionid= has to be in the pasted
>>>> url. I don't recomment this!
>>>>
>>>> ?5 helps when the user refreshes the page in his current session. In
>>>> this case he will see the same content as before the refresh. In 1.4
>>>> he'd see the initial state of the page and will loose any state that
>>>> is not persisted so far.
>>>>
>>>>
>>>>>
>>>>> -igor
>>>>>
>>>>> On Mon, Mar 19, 2012 at 3:52 PM, Pointbreak
>>>>> <po...@ml1.net> wrote:
>>>>>> It's a problem when users bookmark it. Because ...?5 this session is an
>>>>>> entirely other page as ...?5 in another session tomorrow.
>>>>>>
>>>>>> On Mon, Mar 19, 2012, at 11:53, Girts Ziemelis wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 2012-03-19 02:46, Paolo wrote:
>>>>>>> > I support you! I implemented class NoVersionMount thanks to pointbreak
>>>>>>> > in my MainApplication. And It will be my template for future app. But
>>>>>>> > to do it, I needed to understood the problem, check on google, read a
>>>>>>> > lot of pages, without found a solution, so post the question here, and
>>>>>>> > after 3 post, got a right reply for me. Why an wicket user have to do
>>>>>>> > all this???? Why not, wicket use the NoVersionMount as default Mount?
>>>>>>> > Like in wicket 1.4. And implement an VersionMount as an alternative
>>>>>>> > for developer?
>>>>>>> I actually like this change so far. I can finally tell, that my page is
>>>>>>> stetefull just by looking at the link and ask myself question - if I
>>>>>>> really care so much about the clean link for this page, may be it should
>>>>>>> be stateless in a first place?
>>>>>>>
>>>>>>> And why is ?0 such a big problem? It does not cause problems sending
>>>>>>> links.
>>>>>>> Is there any real proof of google indexing problems so far?
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Martin Grigorov
>>>> jWeekend
>>>> Training, Consulting, Development
>>>> http://jWeekend.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Igor Vaynberg <ig...@gmail.com>.
On Tue, Mar 20, 2012 at 8:28 AM, Martin Grigorov <mg...@apache.org> wrote:
> On Tue, Mar 20, 2012 at 5:20 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>> On Tue, Mar 20, 2012 at 1:07 AM, Martin Grigorov <mg...@apache.org> wrote:
>>> On Tue, Mar 20, 2012 at 12:55 AM, Igor Vaynberg <ig...@gmail.com> wrote:
>>>> indeed. we should check that the page pointed to by the id maps back
>>>> to the mount, and create a new instance based on the mount if it
>>>> doesnt. jira please.
>>>
>>> This is already the case, no need of a ticket for this. If there is no
>>> ?5 then Wicket creates ?0 and shows it.
>>
>> this is not what i was talking about...
>>
>>> The "problem" Pointbreak actually mean is that userA may have opened
>>> ?5 in his session, copy the url and give it to
>>> userB, but userB also already have its own session and by chance he
>>> also had reached ?5 and these two ?5s are
>>> different because they may have different states for both users.
>>
>> not only are ?5 different, but they are entirely different pages.
>>
>> so user A goes to /foo, we redirect to /foo?0, they click around and
>> end up on /foo?2
>> user B goes to /bar, we redirect to /bar?0, they click around and end
>> up on /bar?7
>>
>> now user A emails user B the /foo?2 link. when user B hits that link
>> they end up going to a previous version of their *bar* page instead of
>> some instance of /foo because we do not check the mount vs the page
>> id, and whats worse we keep the mount in the url even though we are
>> displaying a page that is not mounted.
>
> Ouch!
>
>>
>> i guess this is why in 1.4 we dropped the mount from nonbookmarkable urls...
>
> I hope you don't mean that we have to redirect to wicket/page?0 from
> the bookmarkable url that the user requested.
no. we should redirect to wicket/page?x when the user navigates away
from the mounted page.
so i go to /bar which is BarPage and end up on /bar?0. click a link
that does something to BarPage, so end up on /bar?1. click a link that
takes me to FooPage, at this point since the page does not match the
mount i should go to /wicket/page?3
-igor
> It'd be better if we check the type of the stored page against the
> type of the page that is mounted at this "bookmarkable" url and throw
> PageExpiredException if they don't match.
>
>>
>> -igor
>>
>>
>>
>>
>>>
>>> The confusing part here is "bookmarkable". Now imagine that there is
>>> no ?pageId in the url. userA clicks several Ajax links to get to
>>> version5 of that page and then copy/paste the url but userB will see
>>> the initial state of the page, not version5 that userA actually meant.
>>> So it seems only ?0 is actually "bookmarkable" for stateful pages.
>>> Only in this case both users will see the same content (if there is no
>>> special logic for user permissions involved).
>>>
>>> If userA wants to fully share his page with userB then he has to share
>>> his session too, i.e. both ?5 and jessionid= has to be in the pasted
>>> url. I don't recomment this!
>>>
>>> ?5 helps when the user refreshes the page in his current session. In
>>> this case he will see the same content as before the refresh. In 1.4
>>> he'd see the initial state of the page and will loose any state that
>>> is not persisted so far.
>>>
>>>
>>>>
>>>> -igor
>>>>
>>>> On Mon, Mar 19, 2012 at 3:52 PM, Pointbreak
>>>> <po...@ml1.net> wrote:
>>>>> It's a problem when users bookmark it. Because ...?5 this session is an
>>>>> entirely other page as ...?5 in another session tomorrow.
>>>>>
>>>>> On Mon, Mar 19, 2012, at 11:53, Girts Ziemelis wrote:
>>>>>>
>>>>>>
>>>>>> On 2012-03-19 02:46, Paolo wrote:
>>>>>> > I support you! I implemented class NoVersionMount thanks to pointbreak
>>>>>> > in my MainApplication. And It will be my template for future app. But
>>>>>> > to do it, I needed to understood the problem, check on google, read a
>>>>>> > lot of pages, without found a solution, so post the question here, and
>>>>>> > after 3 post, got a right reply for me. Why an wicket user have to do
>>>>>> > all this???? Why not, wicket use the NoVersionMount as default Mount?
>>>>>> > Like in wicket 1.4. And implement an VersionMount as an alternative
>>>>>> > for developer?
>>>>>> I actually like this change so far. I can finally tell, that my page is
>>>>>> stetefull just by looking at the link and ask myself question - if I
>>>>>> really care so much about the clean link for this page, may be it should
>>>>>> be stateless in a first place?
>>>>>>
>>>>>> And why is ?0 such a big problem? It does not cause problems sending
>>>>>> links.
>>>>>> Is there any real proof of google indexing problems so far?
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Martin Grigorov
>>> jWeekend
>>> Training, Consulting, Development
>>> http://jWeekend.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Martin Grigorov <mg...@apache.org>.
On Tue, Mar 20, 2012 at 5:20 PM, Igor Vaynberg <ig...@gmail.com> wrote:
> On Tue, Mar 20, 2012 at 1:07 AM, Martin Grigorov <mg...@apache.org> wrote:
>> On Tue, Mar 20, 2012 at 12:55 AM, Igor Vaynberg <ig...@gmail.com> wrote:
>>> indeed. we should check that the page pointed to by the id maps back
>>> to the mount, and create a new instance based on the mount if it
>>> doesnt. jira please.
>>
>> This is already the case, no need of a ticket for this. If there is no
>> ?5 then Wicket creates ?0 and shows it.
>
> this is not what i was talking about...
>
>> The "problem" Pointbreak actually mean is that userA may have opened
>> ?5 in his session, copy the url and give it to
>> userB, but userB also already have its own session and by chance he
>> also had reached ?5 and these two ?5s are
>> different because they may have different states for both users.
>
> not only are ?5 different, but they are entirely different pages.
>
> so user A goes to /foo, we redirect to /foo?0, they click around and
> end up on /foo?2
> user B goes to /bar, we redirect to /bar?0, they click around and end
> up on /bar?7
>
> now user A emails user B the /foo?2 link. when user B hits that link
> they end up going to a previous version of their *bar* page instead of
> some instance of /foo because we do not check the mount vs the page
> id, and whats worse we keep the mount in the url even though we are
> displaying a page that is not mounted.
Ouch!
>
> i guess this is why in 1.4 we dropped the mount from nonbookmarkable urls...
I hope you don't mean that we have to redirect to wicket/page?0 from
the bookmarkable url that the user requested.
It'd be better if we check the type of the stored page against the
type of the page that is mounted at this "bookmarkable" url and throw
PageExpiredException if they don't match.
>
> -igor
>
>
>
>
>>
>> The confusing part here is "bookmarkable". Now imagine that there is
>> no ?pageId in the url. userA clicks several Ajax links to get to
>> version5 of that page and then copy/paste the url but userB will see
>> the initial state of the page, not version5 that userA actually meant.
>> So it seems only ?0 is actually "bookmarkable" for stateful pages.
>> Only in this case both users will see the same content (if there is no
>> special logic for user permissions involved).
>>
>> If userA wants to fully share his page with userB then he has to share
>> his session too, i.e. both ?5 and jessionid= has to be in the pasted
>> url. I don't recomment this!
>>
>> ?5 helps when the user refreshes the page in his current session. In
>> this case he will see the same content as before the refresh. In 1.4
>> he'd see the initial state of the page and will loose any state that
>> is not persisted so far.
>>
>>
>>>
>>> -igor
>>>
>>> On Mon, Mar 19, 2012 at 3:52 PM, Pointbreak
>>> <po...@ml1.net> wrote:
>>>> It's a problem when users bookmark it. Because ...?5 this session is an
>>>> entirely other page as ...?5 in another session tomorrow.
>>>>
>>>> On Mon, Mar 19, 2012, at 11:53, Girts Ziemelis wrote:
>>>>>
>>>>>
>>>>> On 2012-03-19 02:46, Paolo wrote:
>>>>> > I support you! I implemented class NoVersionMount thanks to pointbreak
>>>>> > in my MainApplication. And It will be my template for future app. But
>>>>> > to do it, I needed to understood the problem, check on google, read a
>>>>> > lot of pages, without found a solution, so post the question here, and
>>>>> > after 3 post, got a right reply for me. Why an wicket user have to do
>>>>> > all this???? Why not, wicket use the NoVersionMount as default Mount?
>>>>> > Like in wicket 1.4. And implement an VersionMount as an alternative
>>>>> > for developer?
>>>>> I actually like this change so far. I can finally tell, that my page is
>>>>> stetefull just by looking at the link and ask myself question - if I
>>>>> really care so much about the clean link for this page, may be it should
>>>>> be stateless in a first place?
>>>>>
>>>>> And why is ?0 such a big problem? It does not cause problems sending
>>>>> links.
>>>>> Is there any real proof of google indexing problems so far?
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Igor Vaynberg <ig...@gmail.com>.
On Tue, Mar 20, 2012 at 1:07 AM, Martin Grigorov <mg...@apache.org> wrote:
> On Tue, Mar 20, 2012 at 12:55 AM, Igor Vaynberg <ig...@gmail.com> wrote:
>> indeed. we should check that the page pointed to by the id maps back
>> to the mount, and create a new instance based on the mount if it
>> doesnt. jira please.
>
> This is already the case, no need of a ticket for this. If there is no
> ?5 then Wicket creates ?0 and shows it.
this is not what i was talking about...
> The "problem" Pointbreak actually mean is that userA may have opened
> ?5 in his session, copy the url and give it to
> userB, but userB also already have its own session and by chance he
> also had reached ?5 and these two ?5s are
> different because they may have different states for both users.
not only are ?5 different, but they are entirely different pages.
so user A goes to /foo, we redirect to /foo?0, they click around and
end up on /foo?2
user B goes to /bar, we redirect to /bar?0, they click around and end
up on /bar?7
now user A emails user B the /foo?2 link. when user B hits that link
they end up going to a previous version of their *bar* page instead of
some instance of /foo because we do not check the mount vs the page
id, and whats worse we keep the mount in the url even though we are
displaying a page that is not mounted.
i guess this is why in 1.4 we dropped the mount from nonbookmarkable urls...
-igor
>
> The confusing part here is "bookmarkable". Now imagine that there is
> no ?pageId in the url. userA clicks several Ajax links to get to
> version5 of that page and then copy/paste the url but userB will see
> the initial state of the page, not version5 that userA actually meant.
> So it seems only ?0 is actually "bookmarkable" for stateful pages.
> Only in this case both users will see the same content (if there is no
> special logic for user permissions involved).
>
> If userA wants to fully share his page with userB then he has to share
> his session too, i.e. both ?5 and jessionid= has to be in the pasted
> url. I don't recomment this!
>
> ?5 helps when the user refreshes the page in his current session. In
> this case he will see the same content as before the refresh. In 1.4
> he'd see the initial state of the page and will loose any state that
> is not persisted so far.
>
>
>>
>> -igor
>>
>> On Mon, Mar 19, 2012 at 3:52 PM, Pointbreak
>> <po...@ml1.net> wrote:
>>> It's a problem when users bookmark it. Because ...?5 this session is an
>>> entirely other page as ...?5 in another session tomorrow.
>>>
>>> On Mon, Mar 19, 2012, at 11:53, Girts Ziemelis wrote:
>>>>
>>>>
>>>> On 2012-03-19 02:46, Paolo wrote:
>>>> > I support you! I implemented class NoVersionMount thanks to pointbreak
>>>> > in my MainApplication. And It will be my template for future app. But
>>>> > to do it, I needed to understood the problem, check on google, read a
>>>> > lot of pages, without found a solution, so post the question here, and
>>>> > after 3 post, got a right reply for me. Why an wicket user have to do
>>>> > all this???? Why not, wicket use the NoVersionMount as default Mount?
>>>> > Like in wicket 1.4. And implement an VersionMount as an alternative
>>>> > for developer?
>>>> I actually like this change so far. I can finally tell, that my page is
>>>> stetefull just by looking at the link and ask myself question - if I
>>>> really care so much about the clean link for this page, may be it should
>>>> be stateless in a first place?
>>>>
>>>> And why is ?0 such a big problem? It does not cause problems sending
>>>> links.
>>>> Is there any real proof of google indexing problems so far?
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Pointbreak <po...@ml1.net>.
On Tue, Mar 20, 2012, at 10:50, Martin Grigorov wrote:
> On Tue, Mar 20, 2012 at 10:45 AM, Pointbreak
> <po...@ml1.net> wrote:
> > On Tue, Mar 20, 2012, at 10:40, Martin Grigorov wrote:
> >> On Tue, Mar 20, 2012 at 10:38 AM, Pointbreak
> >> <po...@ml1.net> wrote:
> >> > Yes (sort of) except you don't need two users. Just bookmark a page with
> >> > a version/id e.g. ?5, close the sessions, open a new session, do some
> >> > interaction so that another version of the page with version/id ?5
> >> > exists, and use that bookmark. Stuff like that confuses users even if
> >> > they don't care about "pretty" urls.
> >>
> >> But it is the same in 1.4.
> >> Do some Ajax interactions to swap panels for example, copy the url,
> >> then later paste it and you will see the initial version of the page,
> >> not the one with the swapped panels.
> >>
> >
> > Yes this was also the case in 1.4. But in 1.4 with
> > HybridUrlCodingStrategy you could work around that (sort of).
>
> Please explain.
Sorry for confusion, we didn't use HybridUrlCodingStrategy, but
QueryStringUrlCodingStrategy. It doesn't put the version nr into the url
of stateful pages, but always gives the latest version of a page. That
solves the problem when bookmarking a page (because you don't bookmark a
specific version of a page, but just the page).
(It may however cause problems when users keep two versions of a page
open in two tabs and switch between them, since callbacks on one of them
are not in sync with the latest version.)
> >
> >> >
> >> > On Tue, Mar 20, 2012, at 10:07, Martin Grigorov wrote:
> >> >> On Tue, Mar 20, 2012 at 12:55 AM, Igor Vaynberg <ig...@gmail.com>
> >> >> wrote:
> >> >> > indeed. we should check that the page pointed to by the id maps back
> >> >> > to the mount, and create a new instance based on the mount if it
> >> >> > doesnt. jira please.
> >> >>
> >> >> This is already the case, no need of a ticket for this. If there is no
> >> >> ?5 then Wicket creates ?0 and shows it.
> >> >>
> >> >> The "problem" Pointbreak actually mean is that userA may have opened
> >> >> ?5 in his session, copy the url and give it to
> >> >> userB, but userB also already have its own session and by chance he
> >> >> also had reached ?5 and these two ?5s are
> >> >> different because they may have different states for both users.
> >> >>
> >> >> The confusing part here is "bookmarkable". Now imagine that there is
> >> >> no ?pageId in the url. userA clicks several Ajax links to get to
> >> >> version5 of that page and then copy/paste the url but userB will see
> >> >> the initial state of the page, not version5 that userA actually meant.
> >> >> So it seems only ?0 is actually "bookmarkable" for stateful pages.
> >> >> Only in this case both users will see the same content (if there is no
> >> >> special logic for user permissions involved).
> >> >>
> >> >> If userA wants to fully share his page with userB then he has to share
> >> >> his session too, i.e. both ?5 and jessionid= has to be in the pasted
> >> >> url. I don't recomment this!
> >> >>
> >> >> ?5 helps when the user refreshes the page in his current session. In
> >> >> this case he will see the same content as before the refresh. In 1.4
> >> >> he'd see the initial state of the page and will loose any state that
> >> >> is not persisted so far.
> >> >>
> >> >>
> >> >> >
> >> >> > -igor
> >> >> >
> >> >> > On Mon, Mar 19, 2012 at 3:52 PM, Pointbreak
> >> >> > <po...@ml1.net> wrote:
> >> >> >> It's a problem when users bookmark it. Because ...?5 this session is an
> >> >> >> entirely other page as ...?5 in another session tomorrow.
> >> >> >>
> >> >> >> On Mon, Mar 19, 2012, at 11:53, Girts Ziemelis wrote:
> >> >> >>>
> >> >> >>>
> >> >> >>> On 2012-03-19 02:46, Paolo wrote:
> >> >> >>> > I support you! I implemented class NoVersionMount thanks to pointbreak
> >> >> >>> > in my MainApplication. And It will be my template for future app. But
> >> >> >>> > to do it, I needed to understood the problem, check on google, read a
> >> >> >>> > lot of pages, without found a solution, so post the question here, and
> >> >> >>> > after 3 post, got a right reply for me. Why an wicket user have to do
> >> >> >>> > all this???? Why not, wicket use the NoVersionMount as default Mount?
> >> >> >>> > Like in wicket 1.4. And implement an VersionMount as an alternative
> >> >> >>> > for developer?
> >> >> >>> I actually like this change so far. I can finally tell, that my page is
> >> >> >>> stetefull just by looking at the link and ask myself question - if I
> >> >> >>> really care so much about the clean link for this page, may be it should
> >> >> >>> be stateless in a first place?
> >> >> >>>
> >> >> >>> And why is ?0 such a big problem? It does not cause problems sending
> >> >> >>> links.
> >> >> >>> Is there any real proof of google indexing problems so far?
> >> >> >>>
> >> >> >>>
> >> >> >>> ---------------------------------------------------------------------
> >> >> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >>>
> >> >> >>>
> >> >> >>
> >> >> >> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >>
> >> >> >
> >> >> > ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Martin Grigorov
> >> >> jWeekend
> >> >> Training, Consulting, Development
> >> >> http://jWeekend.com
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >>
> >>
> >>
> >> --
> >> Martin Grigorov
> >> jWeekend
> >> Training, Consulting, Development
> >> http://jWeekend.com
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Martin Grigorov <mg...@apache.org>.
On Tue, Mar 20, 2012 at 10:45 AM, Pointbreak
<po...@ml1.net> wrote:
> On Tue, Mar 20, 2012, at 10:40, Martin Grigorov wrote:
>> On Tue, Mar 20, 2012 at 10:38 AM, Pointbreak
>> <po...@ml1.net> wrote:
>> > Yes (sort of) except you don't need two users. Just bookmark a page with
>> > a version/id e.g. ?5, close the sessions, open a new session, do some
>> > interaction so that another version of the page with version/id ?5
>> > exists, and use that bookmark. Stuff like that confuses users even if
>> > they don't care about "pretty" urls.
>>
>> But it is the same in 1.4.
>> Do some Ajax interactions to swap panels for example, copy the url,
>> then later paste it and you will see the initial version of the page,
>> not the one with the swapped panels.
>>
>
> Yes this was also the case in 1.4. But in 1.4 with
> HybridUrlCodingStrategy you could work around that (sort of).
Please explain.
>
>> >
>> > On Tue, Mar 20, 2012, at 10:07, Martin Grigorov wrote:
>> >> On Tue, Mar 20, 2012 at 12:55 AM, Igor Vaynberg <ig...@gmail.com>
>> >> wrote:
>> >> > indeed. we should check that the page pointed to by the id maps back
>> >> > to the mount, and create a new instance based on the mount if it
>> >> > doesnt. jira please.
>> >>
>> >> This is already the case, no need of a ticket for this. If there is no
>> >> ?5 then Wicket creates ?0 and shows it.
>> >>
>> >> The "problem" Pointbreak actually mean is that userA may have opened
>> >> ?5 in his session, copy the url and give it to
>> >> userB, but userB also already have its own session and by chance he
>> >> also had reached ?5 and these two ?5s are
>> >> different because they may have different states for both users.
>> >>
>> >> The confusing part here is "bookmarkable". Now imagine that there is
>> >> no ?pageId in the url. userA clicks several Ajax links to get to
>> >> version5 of that page and then copy/paste the url but userB will see
>> >> the initial state of the page, not version5 that userA actually meant.
>> >> So it seems only ?0 is actually "bookmarkable" for stateful pages.
>> >> Only in this case both users will see the same content (if there is no
>> >> special logic for user permissions involved).
>> >>
>> >> If userA wants to fully share his page with userB then he has to share
>> >> his session too, i.e. both ?5 and jessionid= has to be in the pasted
>> >> url. I don't recomment this!
>> >>
>> >> ?5 helps when the user refreshes the page in his current session. In
>> >> this case he will see the same content as before the refresh. In 1.4
>> >> he'd see the initial state of the page and will loose any state that
>> >> is not persisted so far.
>> >>
>> >>
>> >> >
>> >> > -igor
>> >> >
>> >> > On Mon, Mar 19, 2012 at 3:52 PM, Pointbreak
>> >> > <po...@ml1.net> wrote:
>> >> >> It's a problem when users bookmark it. Because ...?5 this session is an
>> >> >> entirely other page as ...?5 in another session tomorrow.
>> >> >>
>> >> >> On Mon, Mar 19, 2012, at 11:53, Girts Ziemelis wrote:
>> >> >>>
>> >> >>>
>> >> >>> On 2012-03-19 02:46, Paolo wrote:
>> >> >>> > I support you! I implemented class NoVersionMount thanks to pointbreak
>> >> >>> > in my MainApplication. And It will be my template for future app. But
>> >> >>> > to do it, I needed to understood the problem, check on google, read a
>> >> >>> > lot of pages, without found a solution, so post the question here, and
>> >> >>> > after 3 post, got a right reply for me. Why an wicket user have to do
>> >> >>> > all this???? Why not, wicket use the NoVersionMount as default Mount?
>> >> >>> > Like in wicket 1.4. And implement an VersionMount as an alternative
>> >> >>> > for developer?
>> >> >>> I actually like this change so far. I can finally tell, that my page is
>> >> >>> stetefull just by looking at the link and ask myself question - if I
>> >> >>> really care so much about the clean link for this page, may be it should
>> >> >>> be stateless in a first place?
>> >> >>>
>> >> >>> And why is ?0 such a big problem? It does not cause problems sending
>> >> >>> links.
>> >> >>> Is there any real proof of google indexing problems so far?
>> >> >>>
>> >> >>>
>> >> >>> ---------------------------------------------------------------------
>> >> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >>> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>>
>> >> >>>
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Martin Grigorov
>> >> jWeekend
>> >> Training, Consulting, Development
>> >> http://jWeekend.com
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Pointbreak <po...@ml1.net>.
On Tue, Mar 20, 2012, at 10:40, Martin Grigorov wrote:
> On Tue, Mar 20, 2012 at 10:38 AM, Pointbreak
> <po...@ml1.net> wrote:
> > Yes (sort of) except you don't need two users. Just bookmark a page with
> > a version/id e.g. ?5, close the sessions, open a new session, do some
> > interaction so that another version of the page with version/id ?5
> > exists, and use that bookmark. Stuff like that confuses users even if
> > they don't care about "pretty" urls.
>
> But it is the same in 1.4.
> Do some Ajax interactions to swap panels for example, copy the url,
> then later paste it and you will see the initial version of the page,
> not the one with the swapped panels.
>
Yes this was also the case in 1.4. But in 1.4 with
HybridUrlCodingStrategy you could work around that (sort of).
> >
> > On Tue, Mar 20, 2012, at 10:07, Martin Grigorov wrote:
> >> On Tue, Mar 20, 2012 at 12:55 AM, Igor Vaynberg <ig...@gmail.com>
> >> wrote:
> >> > indeed. we should check that the page pointed to by the id maps back
> >> > to the mount, and create a new instance based on the mount if it
> >> > doesnt. jira please.
> >>
> >> This is already the case, no need of a ticket for this. If there is no
> >> ?5 then Wicket creates ?0 and shows it.
> >>
> >> The "problem" Pointbreak actually mean is that userA may have opened
> >> ?5 in his session, copy the url and give it to
> >> userB, but userB also already have its own session and by chance he
> >> also had reached ?5 and these two ?5s are
> >> different because they may have different states for both users.
> >>
> >> The confusing part here is "bookmarkable". Now imagine that there is
> >> no ?pageId in the url. userA clicks several Ajax links to get to
> >> version5 of that page and then copy/paste the url but userB will see
> >> the initial state of the page, not version5 that userA actually meant.
> >> So it seems only ?0 is actually "bookmarkable" for stateful pages.
> >> Only in this case both users will see the same content (if there is no
> >> special logic for user permissions involved).
> >>
> >> If userA wants to fully share his page with userB then he has to share
> >> his session too, i.e. both ?5 and jessionid= has to be in the pasted
> >> url. I don't recomment this!
> >>
> >> ?5 helps when the user refreshes the page in his current session. In
> >> this case he will see the same content as before the refresh. In 1.4
> >> he'd see the initial state of the page and will loose any state that
> >> is not persisted so far.
> >>
> >>
> >> >
> >> > -igor
> >> >
> >> > On Mon, Mar 19, 2012 at 3:52 PM, Pointbreak
> >> > <po...@ml1.net> wrote:
> >> >> It's a problem when users bookmark it. Because ...?5 this session is an
> >> >> entirely other page as ...?5 in another session tomorrow.
> >> >>
> >> >> On Mon, Mar 19, 2012, at 11:53, Girts Ziemelis wrote:
> >> >>>
> >> >>>
> >> >>> On 2012-03-19 02:46, Paolo wrote:
> >> >>> > I support you! I implemented class NoVersionMount thanks to pointbreak
> >> >>> > in my MainApplication. And It will be my template for future app. But
> >> >>> > to do it, I needed to understood the problem, check on google, read a
> >> >>> > lot of pages, without found a solution, so post the question here, and
> >> >>> > after 3 post, got a right reply for me. Why an wicket user have to do
> >> >>> > all this???? Why not, wicket use the NoVersionMount as default Mount?
> >> >>> > Like in wicket 1.4. And implement an VersionMount as an alternative
> >> >>> > for developer?
> >> >>> I actually like this change so far. I can finally tell, that my page is
> >> >>> stetefull just by looking at the link and ask myself question - if I
> >> >>> really care so much about the clean link for this page, may be it should
> >> >>> be stateless in a first place?
> >> >>>
> >> >>> And why is ?0 such a big problem? It does not cause problems sending
> >> >>> links.
> >> >>> Is there any real proof of google indexing problems so far?
> >> >>>
> >> >>>
> >> >>> ---------------------------------------------------------------------
> >> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>>
> >> >>>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >>
> >>
> >>
> >> --
> >> Martin Grigorov
> >> jWeekend
> >> Training, Consulting, Development
> >> http://jWeekend.com
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Martin Grigorov <mg...@apache.org>.
On Tue, Mar 20, 2012 at 10:38 AM, Pointbreak
<po...@ml1.net> wrote:
> Yes (sort of) except you don't need two users. Just bookmark a page with
> a version/id e.g. ?5, close the sessions, open a new session, do some
> interaction so that another version of the page with version/id ?5
> exists, and use that bookmark. Stuff like that confuses users even if
> they don't care about "pretty" urls.
But it is the same in 1.4.
Do some Ajax interactions to swap panels for example, copy the url,
then later paste it and you will see the initial version of the page,
not the one with the swapped panels.
>
> On Tue, Mar 20, 2012, at 10:07, Martin Grigorov wrote:
>> On Tue, Mar 20, 2012 at 12:55 AM, Igor Vaynberg <ig...@gmail.com>
>> wrote:
>> > indeed. we should check that the page pointed to by the id maps back
>> > to the mount, and create a new instance based on the mount if it
>> > doesnt. jira please.
>>
>> This is already the case, no need of a ticket for this. If there is no
>> ?5 then Wicket creates ?0 and shows it.
>>
>> The "problem" Pointbreak actually mean is that userA may have opened
>> ?5 in his session, copy the url and give it to
>> userB, but userB also already have its own session and by chance he
>> also had reached ?5 and these two ?5s are
>> different because they may have different states for both users.
>>
>> The confusing part here is "bookmarkable". Now imagine that there is
>> no ?pageId in the url. userA clicks several Ajax links to get to
>> version5 of that page and then copy/paste the url but userB will see
>> the initial state of the page, not version5 that userA actually meant.
>> So it seems only ?0 is actually "bookmarkable" for stateful pages.
>> Only in this case both users will see the same content (if there is no
>> special logic for user permissions involved).
>>
>> If userA wants to fully share his page with userB then he has to share
>> his session too, i.e. both ?5 and jessionid= has to be in the pasted
>> url. I don't recomment this!
>>
>> ?5 helps when the user refreshes the page in his current session. In
>> this case he will see the same content as before the refresh. In 1.4
>> he'd see the initial state of the page and will loose any state that
>> is not persisted so far.
>>
>>
>> >
>> > -igor
>> >
>> > On Mon, Mar 19, 2012 at 3:52 PM, Pointbreak
>> > <po...@ml1.net> wrote:
>> >> It's a problem when users bookmark it. Because ...?5 this session is an
>> >> entirely other page as ...?5 in another session tomorrow.
>> >>
>> >> On Mon, Mar 19, 2012, at 11:53, Girts Ziemelis wrote:
>> >>>
>> >>>
>> >>> On 2012-03-19 02:46, Paolo wrote:
>> >>> > I support you! I implemented class NoVersionMount thanks to pointbreak
>> >>> > in my MainApplication. And It will be my template for future app. But
>> >>> > to do it, I needed to understood the problem, check on google, read a
>> >>> > lot of pages, without found a solution, so post the question here, and
>> >>> > after 3 post, got a right reply for me. Why an wicket user have to do
>> >>> > all this???? Why not, wicket use the NoVersionMount as default Mount?
>> >>> > Like in wicket 1.4. And implement an VersionMount as an alternative
>> >>> > for developer?
>> >>> I actually like this change so far. I can finally tell, that my page is
>> >>> stetefull just by looking at the link and ask myself question - if I
>> >>> really care so much about the clean link for this page, may be it should
>> >>> be stateless in a first place?
>> >>>
>> >>> And why is ?0 such a big problem? It does not cause problems sending
>> >>> links.
>> >>> Is there any real proof of google indexing problems so far?
>> >>>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >>> For additional commands, e-mail: users-help@wicket.apache.org
>> >>>
>> >>>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Pointbreak <po...@ml1.net>.
Yes (sort of) except you don't need two users. Just bookmark a page with
a version/id e.g. ?5, close the sessions, open a new session, do some
interaction so that another version of the page with version/id ?5
exists, and use that bookmark. Stuff like that confuses users even if
they don't care about "pretty" urls.
On Tue, Mar 20, 2012, at 10:07, Martin Grigorov wrote:
> On Tue, Mar 20, 2012 at 12:55 AM, Igor Vaynberg <ig...@gmail.com>
> wrote:
> > indeed. we should check that the page pointed to by the id maps back
> > to the mount, and create a new instance based on the mount if it
> > doesnt. jira please.
>
> This is already the case, no need of a ticket for this. If there is no
> ?5 then Wicket creates ?0 and shows it.
>
> The "problem" Pointbreak actually mean is that userA may have opened
> ?5 in his session, copy the url and give it to
> userB, but userB also already have its own session and by chance he
> also had reached ?5 and these two ?5s are
> different because they may have different states for both users.
>
> The confusing part here is "bookmarkable". Now imagine that there is
> no ?pageId in the url. userA clicks several Ajax links to get to
> version5 of that page and then copy/paste the url but userB will see
> the initial state of the page, not version5 that userA actually meant.
> So it seems only ?0 is actually "bookmarkable" for stateful pages.
> Only in this case both users will see the same content (if there is no
> special logic for user permissions involved).
>
> If userA wants to fully share his page with userB then he has to share
> his session too, i.e. both ?5 and jessionid= has to be in the pasted
> url. I don't recomment this!
>
> ?5 helps when the user refreshes the page in his current session. In
> this case he will see the same content as before the refresh. In 1.4
> he'd see the initial state of the page and will loose any state that
> is not persisted so far.
>
>
> >
> > -igor
> >
> > On Mon, Mar 19, 2012 at 3:52 PM, Pointbreak
> > <po...@ml1.net> wrote:
> >> It's a problem when users bookmark it. Because ...?5 this session is an
> >> entirely other page as ...?5 in another session tomorrow.
> >>
> >> On Mon, Mar 19, 2012, at 11:53, Girts Ziemelis wrote:
> >>>
> >>>
> >>> On 2012-03-19 02:46, Paolo wrote:
> >>> > I support you! I implemented class NoVersionMount thanks to pointbreak
> >>> > in my MainApplication. And It will be my template for future app. But
> >>> > to do it, I needed to understood the problem, check on google, read a
> >>> > lot of pages, without found a solution, so post the question here, and
> >>> > after 3 post, got a right reply for me. Why an wicket user have to do
> >>> > all this???? Why not, wicket use the NoVersionMount as default Mount?
> >>> > Like in wicket 1.4. And implement an VersionMount as an alternative
> >>> > for developer?
> >>> I actually like this change so far. I can finally tell, that my page is
> >>> stetefull just by looking at the link and ask myself question - if I
> >>> really care so much about the clean link for this page, may be it should
> >>> be stateless in a first place?
> >>>
> >>> And why is ?0 such a big problem? It does not cause problems sending
> >>> links.
> >>> Is there any real proof of google indexing problems so far?
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Martin Grigorov <mg...@apache.org>.
On Tue, Mar 20, 2012 at 12:55 AM, Igor Vaynberg <ig...@gmail.com> wrote:
> indeed. we should check that the page pointed to by the id maps back
> to the mount, and create a new instance based on the mount if it
> doesnt. jira please.
This is already the case, no need of a ticket for this. If there is no
?5 then Wicket creates ?0 and shows it.
The "problem" Pointbreak actually mean is that userA may have opened
?5 in his session, copy the url and give it to
userB, but userB also already have its own session and by chance he
also had reached ?5 and these two ?5s are
different because they may have different states for both users.
The confusing part here is "bookmarkable". Now imagine that there is
no ?pageId in the url. userA clicks several Ajax links to get to
version5 of that page and then copy/paste the url but userB will see
the initial state of the page, not version5 that userA actually meant.
So it seems only ?0 is actually "bookmarkable" for stateful pages.
Only in this case both users will see the same content (if there is no
special logic for user permissions involved).
If userA wants to fully share his page with userB then he has to share
his session too, i.e. both ?5 and jessionid= has to be in the pasted
url. I don't recomment this!
?5 helps when the user refreshes the page in his current session. In
this case he will see the same content as before the refresh. In 1.4
he'd see the initial state of the page and will loose any state that
is not persisted so far.
>
> -igor
>
> On Mon, Mar 19, 2012 at 3:52 PM, Pointbreak
> <po...@ml1.net> wrote:
>> It's a problem when users bookmark it. Because ...?5 this session is an
>> entirely other page as ...?5 in another session tomorrow.
>>
>> On Mon, Mar 19, 2012, at 11:53, Girts Ziemelis wrote:
>>>
>>>
>>> On 2012-03-19 02:46, Paolo wrote:
>>> > I support you! I implemented class NoVersionMount thanks to pointbreak
>>> > in my MainApplication. And It will be my template for future app. But
>>> > to do it, I needed to understood the problem, check on google, read a
>>> > lot of pages, without found a solution, so post the question here, and
>>> > after 3 post, got a right reply for me. Why an wicket user have to do
>>> > all this???? Why not, wicket use the NoVersionMount as default Mount?
>>> > Like in wicket 1.4. And implement an VersionMount as an alternative
>>> > for developer?
>>> I actually like this change so far. I can finally tell, that my page is
>>> stetefull just by looking at the link and ask myself question - if I
>>> really care so much about the clean link for this page, may be it should
>>> be stateless in a first place?
>>>
>>> And why is ?0 such a big problem? It does not cause problems sending
>>> links.
>>> Is there any real proof of google indexing problems so far?
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Igor Vaynberg <ig...@gmail.com>.
indeed. we should check that the page pointed to by the id maps back
to the mount, and create a new instance based on the mount if it
doesnt. jira please.
-igor
On Mon, Mar 19, 2012 at 3:52 PM, Pointbreak
<po...@ml1.net> wrote:
> It's a problem when users bookmark it. Because ...?5 this session is an
> entirely other page as ...?5 in another session tomorrow.
>
> On Mon, Mar 19, 2012, at 11:53, Girts Ziemelis wrote:
>>
>>
>> On 2012-03-19 02:46, Paolo wrote:
>> > I support you! I implemented class NoVersionMount thanks to pointbreak
>> > in my MainApplication. And It will be my template for future app. But
>> > to do it, I needed to understood the problem, check on google, read a
>> > lot of pages, without found a solution, so post the question here, and
>> > after 3 post, got a right reply for me. Why an wicket user have to do
>> > all this???? Why not, wicket use the NoVersionMount as default Mount?
>> > Like in wicket 1.4. And implement an VersionMount as an alternative
>> > for developer?
>> I actually like this change so far. I can finally tell, that my page is
>> stetefull just by looking at the link and ask myself question - if I
>> really care so much about the clean link for this page, may be it should
>> be stateless in a first place?
>>
>> And why is ?0 such a big problem? It does not cause problems sending
>> links.
>> Is there any real proof of google indexing problems so far?
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Pointbreak <po...@ml1.net>.
It's a problem when users bookmark it. Because ...?5 this session is an
entirely other page as ...?5 in another session tomorrow.
On Mon, Mar 19, 2012, at 11:53, Girts Ziemelis wrote:
>
>
> On 2012-03-19 02:46, Paolo wrote:
> > I support you! I implemented class NoVersionMount thanks to pointbreak
> > in my MainApplication. And It will be my template for future app. But
> > to do it, I needed to understood the problem, check on google, read a
> > lot of pages, without found a solution, so post the question here, and
> > after 3 post, got a right reply for me. Why an wicket user have to do
> > all this???? Why not, wicket use the NoVersionMount as default Mount?
> > Like in wicket 1.4. And implement an VersionMount as an alternative
> > for developer?
> I actually like this change so far. I can finally tell, that my page is
> stetefull just by looking at the link and ask myself question - if I
> really care so much about the clean link for this page, may be it should
> be stateless in a first place?
>
> And why is ?0 such a big problem? It does not cause problems sending
> links.
> Is there any real proof of google indexing problems so far?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Girts Ziemelis <gi...@gmail.com>.
On 2012-03-19 02:46, Paolo wrote:
> I support you! I implemented class NoVersionMount thanks to pointbreak
> in my MainApplication. And It will be my template for future app. But
> to do it, I needed to understood the problem, check on google, read a
> lot of pages, without found a solution, so post the question here, and
> after 3 post, got a right reply for me. Why an wicket user have to do
> all this???? Why not, wicket use the NoVersionMount as default Mount?
> Like in wicket 1.4. And implement an VersionMount as an alternative
> for developer?
I actually like this change so far. I can finally tell, that my page is
stetefull just by looking at the link and ask myself question - if I
really care so much about the clean link for this page, may be it should
be stateless in a first place?
And why is ?0 such a big problem? It does not cause problems sending links.
Is there any real proof of google indexing problems so far?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: What real life scenario calls for page ID?
Posted by Paolo <ir...@gmail.com>.
Alle lunedì 19 marzo 2012, Chris Colman ha scritto:
> I've been thinking about the new 1.5 page ID/versioning feature (which
> we disabled as soon as we discovered it) and wondering if there is
> actually a real world scenario for stateful pages that actually requires
> this functionality.
>
> I understand the purpose is so that the browser's 'Back' function can
> work "properly" (and maybe efficiently) but, in all the scenarios we
> have at least, "proper" would be to re-render and not pull the page from
> the cache.
>
> For example, an online store with the current shopping cart displayed in
> the right hand column:
>
> Browser is showing page for product A, no products in shopping cart
> shown in right column.
>
> User goes to page for product B, adds product B to shopping cart.
>
> Hit's back button.
>
> Now wouldn't the 'page versioning/id' feature now show the cached page
> for product A with a shopping cart that is still empty even though the
> user just added product B? Or would it realize that the shopping cart
> panel's model has changed and update it to reflect the newly added item?
>
> In this scenario showing an empty shopping cart is a very definite
> incorrect behavior that will freak out the user who believes that they
> have added a product B (which they have) but it is not shown in the
> shopping cart.
>
> 1.4 functionality (without page ID) worked fine. We never had a single
> complaint about back button not displaying the correct result.
>
> I'm half doubting whether page ID is a useful feature but half wondering
> if it is a useful feature for which I just haven't discovered useful
> scenarios where it is of benefit and so I should find these scenarios
> and change my design to use it.
>
> Thoughts?
I support you!
I implemented class NoVersionMount thanks to pointbreak in my MainApplication.
And It will be my template for future app.
But to do it, I needed to understood the problem, check on google, read a lot of pages,
without found a solution, so post the question here, and after 3 post, got a right reply for me.
Why an wicket user have to do all this????
Why not, wicket use the NoVersionMount as default Mount? Like in wicket 1.4.
And implement an VersionMount as an alternative for developer?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org