You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by kamiseq <ka...@gmail.com> on 2012/01/07 23:24:43 UTC
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.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
thanks for help
pozdrawiam
Paweł Kamiński
kamiseq@gmail.com
pkaminski.prv@gmail.com
______________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: stateless, not versioned pages - session problem
Posted by kamiseq <ka...@gmail.com>.
ok currently im using 1.5.3 i ll check with snapshot
pozdrawiam
Paweł Kamiński
kamiseq@gmail.com
pkaminski.prv@gmail.com
______________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: stateless, not versioned pages - session problem
Posted by kamiseq <ka...@gmail.com>.
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
kamiseq@gmail.com
pkaminski.prv@gmail.com
______________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: stateless, not versioned pages - session problem
Posted by Martin Grigorov <mg...@apache.org>.
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
<ch...@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:mgrigorov@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
>><ch...@stepaheadsoftware.com> wrote:
>>>>On Sun, Jan 8, 2012 at 11:31 AM, Chris Colman
>>>><ch...@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-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: stateless, not versioned pages - session problem
Posted by kamiseq <ka...@gmail.com>.
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
kamiseq@gmail.com
pkaminski.prv@gmail.com
______________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: stateless, not versioned pages - session problem
Posted by kamiseq <ka...@gmail.com>.
any ideas about #base_domain=mydomain.com problem ;]
pozdrawiam
Paweł Kamiński
kamiseq@gmail.com
pkaminski.prv@gmail.com
______________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: stateless, not versioned pages - session problem
Posted by kamiseq <ka...@gmail.com>.
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
kamiseq@gmail.com
pkaminski.prv@gmail.com
______________________
On 9 January 2012 12:39, Chris Colman <ch...@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:mgrigorov@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
>><ch...@stepaheadsoftware.com> wrote:
>>>>On Sun, Jan 8, 2012 at 11:31 AM, Chris Colman
>>>><ch...@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-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: stateless, not versioned pages - session problem
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
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:mgrigorov@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
><ch...@stepaheadsoftware.com> wrote:
>>>On Sun, Jan 8, 2012 at 11:31 AM, Chris Colman
>>><ch...@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-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: stateless, not versioned pages - session problem
Posted by Martin Grigorov <mg...@apache.org>.
On Sun, Jan 8, 2012 at 4:29 PM, Chris Colman
<ch...@stepaheadsoftware.com> wrote:
>>On Sun, Jan 8, 2012 at 11:31 AM, Chris Colman
>><ch...@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-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: stateless, not versioned pages - session problem
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
>On Sun, Jan 8, 2012 at 11:31 AM, Chris Colman
><ch...@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-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: stateless, not versioned pages - session problem
Posted by Martin Grigorov <mg...@apache.org>.
On Sun, Jan 8, 2012 at 11:31 AM, Chris Colman
<ch...@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-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: stateless, not versioned pages - session problem
Posted by Chris Colman <ch...@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.
So would
getPageSettings().setVersionPagesByDefault(false);
have been a better/safer option for turning off page versioning?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: stateless, not versioned pages - session problem
Posted by Martin Grigorov <mg...@apache.org>.
2012/1/8 Chris Colman <ch...@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:kamiseq@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
>>
>>kamiseq@gmail.com
>>pkaminski.prv@gmail.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: stateless, not versioned pages - session problem
Posted by Chris Colman <ch...@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);
which worked.
The interesting thing was it was not necessary to call:
getPageSettings().setVersionPagesByDefault(false);
explicitly.
>-----Original Message-----
>From: kamiseq [mailto:kamiseq@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
>
>kamiseq@gmail.com
>pkaminski.prv@gmail.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: stateless, not versioned pages - session problem
Posted by Martin Grigorov <mg...@apache.org>.
Hej,
On Sun, Jan 8, 2012 at 12:24 AM, kamiseq <ka...@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
>
> kamiseq@gmail.com
> pkaminski.prv@gmail.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