Re: stateless, not versioned pages - session problem
On Sun, Jan 8, 2012 at 4:29 PM, Chris Colman chr...@stepaheadsoftware.com wrote: On Sun, Jan 8, 2012 at 11:31 AM, Chris Colman chr...@stepaheadsoftware.com wrote: Not sure if I have an answer to your question but recently I asked how to turn off page versioning and was told to do: getRequestCycleSettings(). setRenderStrategy(IRequestCycleSettings.RenderStrategy.ONE_PASS_RENDER); Actually this just turns off the redirecting. The pages are still versioned. So would getPageSettings().setVersionPagesByDefault(false); have been a better/safer option for turning off page versioning? Yes. I tried setVesionPagesByDefault(false) on its own but the version parameters still appeared in the URL in the browser address bar. Should we use both of the above to make page versioning disappear so as to make Wicket 1.5 behave just like version 1.5? Make your page stateless to not have page ids in the URL (and the page wont be saved in the page stores too). Otherwise you'll need special version of org.apache.wicket.request.mapper.MountedMapper#mapHandler that doesn't org.apache.wicket.request.mapper.AbstractComponentMapper#encodePageComponentInfo for IPageRequestHandler. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: stateless, not versioned pages - session problem
The stateless/stateful issue, on the surface at least, seems to be trivially easy because it's so black and white. Obviously in an ideal world most pages should be made stateless but in all but trivial sites this is near impossible. I'd like to suggest there is a fair amount of 'gray' - that things aren't so 'black and white' in the real world. For example - the content on most of the pages on our sites are essentially stateless - showing product details or FAQ pages or About Us pages until you realize that *every* web app that has authentication (which one doesn't these days?) shows the currently logged on user's username in an 'account details' component in the top/right of each page with an option to change profile settings and log out etc,. This has become much more than just a convention - it's virtually a defacto standard. Once we add that very common account details component to the top of each page the pages essentially become stateful so essentially a site with predominantly stateless pages now has to be stateful. The main issue that I am trying to avoid by removing page versions is SEO confusion whereby each time a search engine looks at a URL it sees a different page version parameter in the URL. It's a similar problem to the famous jsessionid parameter issue. Given that search engines never authenticate it prompts the question: is it possible for a given page to have multiple personalities? i.e. stateless if no authentication has taken place and stateful if authentication has taken place. User's don't really care if there is an extra page version parameter in the URL and this can be of great assistance in making the back button function correctly - especially if their interactions have changed content on the various pages (eg. showing contents of their shopping cart - hmmm, that's a problem - probably always want to show the 'current' shopping cart contents no matter how much they have gone 'back' otherwise things could get quite confusing) Search engines, on the other hand, don't really want to see the extra page version parameter. Setting up pages to have dual personalities would be a most excellent solution methinks. Is this possible/easy/a good idea in Wicket? Is it something that is such a common requirement that it could be added to the Wicket framework as a built in feature and save hours of work for both experienced and newbie Wicketeers? If it were a switchable option built into the framework wicket would only need to query the AuthenticatedWebSession.isSignedIn() to determine if each page should be stateless or stateful. Or perhaps an IAuthenticator interface needs to be supplied to allow it to work for developers who implement their own authenticated session object. Just thinking aloud ... again ;) Regards, Chrisco -Original Message- From: Martin Grigorov [mailto:mgrigo...@apache.org] Sent: Monday, 9 January 2012 8:37 PM To: users@wicket.apache.org Subject: Re: stateless, not versioned pages - session problem On Sun, Jan 8, 2012 at 4:29 PM, Chris Colman chr...@stepaheadsoftware.com wrote: On Sun, Jan 8, 2012 at 11:31 AM, Chris Colman chr...@stepaheadsoftware.com wrote: Not sure if I have an answer to your question but recently I asked how to turn off page versioning and was told to do: getRequestCycleSettings(). setRenderStrategy(IRequestCycleSettings.RenderStrategy.ONE_PASS_RENDER); Actually this just turns off the redirecting. The pages are still versioned. So would getPageSettings().setVersionPagesByDefault(false); have been a better/safer option for turning off page versioning? Yes. I tried setVesionPagesByDefault(false) on its own but the version parameters still appeared in the URL in the browser address bar. Should we use both of the above to make page versioning disappear so as to make Wicket 1.5 behave just like version 1.5? Make your page stateless to not have page ids in the URL (and the page wont be saved in the page stores too). Otherwise you'll need special version of org.apache.wicket.request.mapper.MountedMapper#mapHandler that doesn't org.apache.wicket.request.mapper.AbstractComponentMapper#encodePageComponen tInfo for IPageRequestHandler. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
Re: stateless, not versioned pages - session problem
Hi, I see there is a big misunderstanding of what stateless/ful actually is. Having an http session or not is related only to the fact that stateful pages are stored there. Nothing more. You still can have an authenticated user (i.e. http session) and show stateless pages. All user info panels that you mentioned below doesn't require stateful page by itself. A page is stateful if it has at least one stateful component or behavior. A stateful component/behavior (C/B)is one that keeps a state with it and that state is needed by the C/B in the next request(s). Such C/B may have a callback url - an url which uniquely identifies this C/B and this C/B can be requested. In the simple and most used case imagine a Link with its onClick() method. So if you keep your pages stateless (by avoiding components and behaviors which makes it stateful. See StatelessChecker in wicket-devutils.jar) you can still show user's account info. A common use case is with Ajax C/Bs. An Ajax call updates just a part of the page. By default Wicket provides stateful Ajax C/Bs, i.e. they update parts of the same page instance. Jolira's Ajax C/Bs are stateless - i.e. an Ajax call creates a completely new page, then updates the part(s) it needs, then delivers the markup for the updated components in the Ajax response and discards the newly created page. I guess we need to create a Wiki page that better explains what is the difference between stateless and stateful. On Mon, Jan 9, 2012 at 1:39 PM, Chris Colman chr...@stepaheadsoftware.com wrote: The stateless/stateful issue, on the surface at least, seems to be trivially easy because it's so black and white. Obviously in an ideal world most pages should be made stateless but in all but trivial sites this is near impossible. I'd like to suggest there is a fair amount of 'gray' - that things aren't so 'black and white' in the real world. For example - the content on most of the pages on our sites are essentially stateless - showing product details or FAQ pages or About Us pages until you realize that *every* web app that has authentication (which one doesn't these days?) shows the currently logged on user's username in an 'account details' component in the top/right of each page with an option to change profile settings and log out etc,. This has become much more than just a convention - it's virtually a defacto standard. Once we add that very common account details component to the top of each page the pages essentially become stateful so essentially a site with predominantly stateless pages now has to be stateful. The main issue that I am trying to avoid by removing page versions is SEO confusion whereby each time a search engine looks at a URL it sees a different page version parameter in the URL. It's a similar problem to the famous jsessionid parameter issue. Given that search engines never authenticate it prompts the question: is it possible for a given page to have multiple personalities? i.e. stateless if no authentication has taken place and stateful if authentication has taken place. User's don't really care if there is an extra page version parameter in the URL and this can be of great assistance in making the back button function correctly - especially if their interactions have changed content on the various pages (eg. showing contents of their shopping cart - hmmm, that's a problem - probably always want to show the 'current' shopping cart contents no matter how much they have gone 'back' otherwise things could get quite confusing) Search engines, on the other hand, don't really want to see the extra page version parameter. Setting up pages to have dual personalities would be a most excellent solution methinks. Is this possible/easy/a good idea in Wicket? Is it something that is such a common requirement that it could be added to the Wicket framework as a built in feature and save hours of work for both experienced and newbie Wicketeers? If it were a switchable option built into the framework wicket would only need to query the AuthenticatedWebSession.isSignedIn() to determine if each page should be stateless or stateful. Or perhaps an IAuthenticator interface needs to be supplied to allow it to work for developers who implement their own authenticated session object. Just thinking aloud ... again ;) Regards, Chrisco -Original Message- From: Martin Grigorov [mailto:mgrigo...@apache.org] Sent: Monday, 9 January 2012 8:37 PM To: users@wicket.apache.org Subject: Re: stateless, not versioned pages - session problem On Sun, Jan 8, 2012 at 4:29 PM, Chris Colman chr...@stepaheadsoftware.com wrote: On Sun, Jan 8, 2012 at 11:31 AM, Chris Colman chr...@stepaheadsoftware.com wrote: Not sure if I have an answer to your question but recently I asked how to turn off page versioning and was told to do: getRequestCycleSettings(). setRenderStrategy
Re: stateless, not versioned pages - session problem
this should go to separate conversation I created stateless (no stateful components) page if user is authorized i put his id to session so I can load it on each page creation (since it is stateless and not versioned it will be created on each request) pozdrawiam Paweł Kamiński kami...@gmail.com pkaminski@gmail.com __ On 9 January 2012 12:39, Chris Colman chr...@stepaheadsoftware.com wrote: The stateless/stateful issue, on the surface at least, seems to be trivially easy because it's so black and white. Obviously in an ideal world most pages should be made stateless but in all but trivial sites this is near impossible. I'd like to suggest there is a fair amount of 'gray' - that things aren't so 'black and white' in the real world. For example - the content on most of the pages on our sites are essentially stateless - showing product details or FAQ pages or About Us pages until you realize that *every* web app that has authentication (which one doesn't these days?) shows the currently logged on user's username in an 'account details' component in the top/right of each page with an option to change profile settings and log out etc,. This has become much more than just a convention - it's virtually a defacto standard. Once we add that very common account details component to the top of each page the pages essentially become stateful so essentially a site with predominantly stateless pages now has to be stateful. The main issue that I am trying to avoid by removing page versions is SEO confusion whereby each time a search engine looks at a URL it sees a different page version parameter in the URL. It's a similar problem to the famous jsessionid parameter issue. Given that search engines never authenticate it prompts the question: is it possible for a given page to have multiple personalities? i.e. stateless if no authentication has taken place and stateful if authentication has taken place. User's don't really care if there is an extra page version parameter in the URL and this can be of great assistance in making the back button function correctly - especially if their interactions have changed content on the various pages (eg. showing contents of their shopping cart - hmmm, that's a problem - probably always want to show the 'current' shopping cart contents no matter how much they have gone 'back' otherwise things could get quite confusing) Search engines, on the other hand, don't really want to see the extra page version parameter. Setting up pages to have dual personalities would be a most excellent solution methinks. Is this possible/easy/a good idea in Wicket? Is it something that is such a common requirement that it could be added to the Wicket framework as a built in feature and save hours of work for both experienced and newbie Wicketeers? If it were a switchable option built into the framework wicket would only need to query the AuthenticatedWebSession.isSignedIn() to determine if each page should be stateless or stateful. Or perhaps an IAuthenticator interface needs to be supplied to allow it to work for developers who implement their own authenticated session object. Just thinking aloud ... again ;) Regards, Chrisco -Original Message- From: Martin Grigorov [mailto:mgrigo...@apache.org] Sent: Monday, 9 January 2012 8:37 PM To: users@wicket.apache.org Subject: Re: stateless, not versioned pages - session problem On Sun, Jan 8, 2012 at 4:29 PM, Chris Colman chr...@stepaheadsoftware.com wrote: On Sun, Jan 8, 2012 at 11:31 AM, Chris Colman chr...@stepaheadsoftware.com wrote: Not sure if I have an answer to your question but recently I asked how to turn off page versioning and was told to do: getRequestCycleSettings(). setRenderStrategy(IRequestCycleSettings.RenderStrategy.ONE_PASS_RENDER); Actually this just turns off the redirecting. The pages are still versioned. So would getPageSettings().setVersionPagesByDefault(false); have been a better/safer option for turning off page versioning? Yes. I tried setVesionPagesByDefault(false) on its own but the version parameters still appeared in the URL in the browser address bar. Should we use both of the above to make page versioning disappear so as to make Wicket 1.5 behave just like version 1.5? Make your page stateless to not have page ids in the URL (and the page wont be saved in the page stores too). Otherwise you'll need special version of org.apache.wicket.request.mapper.MountedMapper#mapHandler that doesn't org.apache.wicket.request.mapper.AbstractComponentMapper#encodePageComponen tInfo for IPageRequestHandler. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
Re: stateless, not versioned pages - session problem
any ideas about #base_domain=mydomain.com problem ;] pozdrawiam Paweł Kamiński kami...@gmail.com pkaminski@gmail.com __ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: stateless, not versioned pages - session problem
ok I found the reason oAuth provider adds this #base_domain to callback url. I just dont understand why it stayed after redirection. the other issue (that after redirect urls looks like callback) is that I use ReplaceHandlerException and I rewrite data from original response to preserve cookies. so I will look at this pozdrawiam Paweł Kamiński kami...@gmail.com pkaminski@gmail.com __ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: stateless, not versioned pages - session problem
Hej, On Sun, Jan 8, 2012 at 12:24 AM, kamiseq kami...@gmail.com wrote: hej I have weird problem with session that I cannot explain and that I don't fully understand. I started with default application settings and stateful web page. and the flow is that I 1. request homepage 2. put data to session 3. redirect to authorize with oauth provider (facebook, gmail, etc) which in turn redirects back to my page 4. get data saved before in session 5. redirect to homepage then I made page stateless and it works perfectly fine until I set getPageSettings().setVersionPagesByDefault(false); (I dont need back button functionality) then session was not created even though I put there something (well it is not quite right session is created but not persisted between requests - just after I put to session I can get the data from session, but on next request to wicket data is gone). To solve it do: Session.get().bind() when you add the attribute(s). I think Wicket should do that for you automatically. Please file a ticket and we will consider it. can you explain why is that? one more thing after last redirect (step 5) wicket added ?#base_domain=mydomain.com to url. when I set getRequestCycleSettings().setRenderStrategy(IRequestCycleSettings.RenderStrategy.ONE_PASS_RENDER); url is as oauth callback (from step 3) and I would expect it to be clean homepage url (ex mydomain.com/) for both render strategies can you try with Wicket 1.5-SNAPSHOT ? Recently we fixed something that automatically added the page parameters to the generated urls. thanks for help pozdrawiam Paweł Kamiński kami...@gmail.com pkaminski@gmail.com __ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: stateless, not versioned pages - session problem
2012/1/8 Chris Colman chr...@stepaheadsoftware.com: Not sure if I have an answer to your question but recently I asked how to turn off page versioning and was told to do: getRequestCycleSettings(). setRenderStrategy(IRequestCycleSettings.RenderStrategy.ONE_PASS_RENDER); Actually this just turns off the redirecting. The pages are still versioned. which worked. The interesting thing was it was not necessary to call: getPageSettings().setVersionPagesByDefault(false); explicitly. -Original Message- From: kamiseq [mailto:kami...@gmail.com] Sent: Sunday, 8 January 2012 9:25 AM To: users@wicket.apache.org Subject: stateless, not versioned pages - session problem hej I have weird problem with session that I cannot explain and that I don't fully understand. I started with default application settings and stateful web page. and the flow is that I 1. request homepage 2. put data to session 3. redirect to authorize with oauth provider (facebook, gmail, etc) which in turn redirects back to my page 4. get data saved before in session 5. redirect to homepage then I made page stateless and it works perfectly fine until I set getPageSettings().setVersionPagesByDefault(false); (I dont need back button functionality) then session was not created even though I put there something (well it is not quite right session is created but not persisted between requests - just after I put to session I can get the data from session, but on next request to wicket data is gone). can you explain why is that? one more thing after last redirect (step 5) wicket added ?#base_domain=mydomain.com to url. when I set getRequestCycleSettings().setRenderStrategy(IRequestCycleSettings.RenderStr ategy.ONE_PASS_RENDER); url is as oauth callback (from step 3) and I would expect it to be clean homepage url (ex mydomain.com/) for both render strategies thanks for help pozdrawiam Paweł Kamiński kami...@gmail.com pkaminski@gmail.com __ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: stateless, not versioned pages - session problem
Not sure if I have an answer to your question but recently I asked how to turn off page versioning and was told to do: getRequestCycleSettings(). setRenderStrategy(IRequestCycleSettings.RenderStrategy.ONE_PASS_RENDER); Actually this just turns off the redirecting. The pages are still versioned. So would getPageSettings().setVersionPagesByDefault(false); have been a better/safer option for turning off page versioning? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: stateless, not versioned pages - session problem
On Sun, Jan 8, 2012 at 11:31 AM, Chris Colman chr...@stepaheadsoftware.com wrote: Not sure if I have an answer to your question but recently I asked how to turn off page versioning and was told to do: getRequestCycleSettings(). setRenderStrategy(IRequestCycleSettings.RenderStrategy.ONE_PASS_RENDER); Actually this just turns off the redirecting. The pages are still versioned. So would getPageSettings().setVersionPagesByDefault(false); have been a better/safer option for turning off page versioning? Yes. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: stateless, not versioned pages - session problem
ok currently im using 1.5.3 i ll check with snapshot pozdrawiam Paweł Kamiński kami...@gmail.com pkaminski@gmail.com __ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: stateless, not versioned pages - session problem
On Sun, Jan 8, 2012 at 11:31 AM, Chris Colman chr...@stepaheadsoftware.com wrote: Not sure if I have an answer to your question but recently I asked how to turn off page versioning and was told to do: getRequestCycleSettings(). setRenderStrategy(IRequestCycleSettings.RenderStrategy.ONE_PASS_RENDER); Actually this just turns off the redirecting. The pages are still versioned. So would getPageSettings().setVersionPagesByDefault(false); have been a better/safer option for turning off page versioning? Yes. I tried setVesionPagesByDefault(false) on its own but the version parameters still appeared in the URL in the browser address bar. Should we use both of the above to make page versioning disappear so as to make Wicket 1.5 behave just like version 1.5? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: stateless, not versioned pages - session problem
ok so bind on session does the trick. now I looked at setAttribute method and I dont understand why the flow is altered when session is temporary. unfortunately I still get this #base_domain=mydoamin. so 1.5-SNAPSHOT behaves like 1.5.3 now I looked closely to url after last redirect to homepage (using ONE_PASS_RENDER strategy) and it is exactly the same as oauth callback plus this #base_domain=mydomain.com parameter :/ when I use default RenderStrategy.REDIRECT_TO_BUFFER then I just get #base_domain=mydomain parameter any ideas? pozdrawiam Paweł Kamiński kami...@gmail.com pkaminski@gmail.com __ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: stateless, not versioned pages - session problem
Not sure if I have an answer to your question but recently I asked how to turn off page versioning and was told to do: getRequestCycleSettings(). setRenderStrategy(IRequestCycleSettings.RenderStrategy.ONE_PASS_RENDER); which worked. The interesting thing was it was not necessary to call: getPageSettings().setVersionPagesByDefault(false); explicitly. -Original Message- From: kamiseq [mailto:kami...@gmail.com] Sent: Sunday, 8 January 2012 9:25 AM To: users@wicket.apache.org Subject: stateless, not versioned pages - session problem hej I have weird problem with session that I cannot explain and that I don't fully understand. I started with default application settings and stateful web page. and the flow is that I 1. request homepage 2. put data to session 3. redirect to authorize with oauth provider (facebook, gmail, etc) which in turn redirects back to my page 4. get data saved before in session 5. redirect to homepage then I made page stateless and it works perfectly fine until I set getPageSettings().setVersionPagesByDefault(false); (I dont need back button functionality) then session was not created even though I put there something (well it is not quite right session is created but not persisted between requests - just after I put to session I can get the data from session, but on next request to wicket data is gone). can you explain why is that? one more thing after last redirect (step 5) wicket added ?#base_domain=mydomain.com to url. when I set getRequestCycleSettings().setRenderStrategy(IRequestCycleSettings.RenderStr ategy.ONE_PASS_RENDER); url is as oauth callback (from step 3) and I would expect it to be clean homepage url (ex mydomain.com/) for both render strategies thanks for help pozdrawiam Paweł Kamiński kami...@gmail.com pkaminski@gmail.com __ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
