Hi Martin,
This doesn't seem to fix the issue. The flash messages are not carried
over to Page1 and the cookie is not set in the 302 to Page1.
I did it like this:
private boolean doRedirect;
Page2(Parameters) {
if( whatever ) {
doRedirect = true;
}
}
@Override
protected void onBeforeRender() {
if(doRedirect) {
setACookie();
Session.get().info("blah");
setResponsePage(Page1.class);
}
}
I know the cookie setting bit is fixed in WICKET-4358, so I'm not too
worried about that. It's really the session flash messages that I can't
figure out how to keep after redirect.
I guess I'll wait for the more detailed answer :)
Bertrand
On 29/06/2012 9:35 AM, Martin Grigorov wrote:
Hi Bertrand,
I'll write a more detailed answer to your mail later.
Until then you can try to workaround it by calling 'setResponsePage()'
in #onBeforeRender() instead.
On Fri, Jun 29, 2012 at 4:21 PM, Bertrand Guay-Paquet
<ber...@step.polymtl.ca> wrote:
Hi Ian,
Thanks for your reply. By the way, I forgot to mention I'm using Wicket
1.5.7.
The (pseudo) code I wrote in my previous email is in Page2's constructor. I
tried both approaches and here are the results:
setResponsePage in page constructor:
-Cookie not set<=== Cookie SET with patch from WICKET-4358
-Session message not displayed on Page1
setResponsePage in form onSubmit:
-Cookie set
-Session message displayed on Page1
So you were right.
However, I really need to redirect from a page constructor because Page2 is
a callback url for an OAuth provider (Facebook in this case). It's actually
Facebook who redirects to Page1 and they don't allow query parameters in the
callback url so I can't use a link listener as a workaround.
Bertrand
On 29/06/2012 4:21 AM, Ian Marshall wrote:
Hello Bertrand,
Where is your Page2 code fragment called? Is in the page constructor, in a
page component onSubmit() method, or somewhere else?
My guess is that your code fragment is called in the page constructor. If
this is so, then:
· I might expect the differences in behaviour you experience between
setResponsePage(WebPage.class) and using a RestartResponseException (as
always, I am open to contradiction).
· If possible, can you move your code to a component onSubmit() method
(of Page2 or the previous page, if any)?
Regards,
Ian
Bertrand Guay-Paquet wrote
Hi,
I have 2 pages, each with a feedback panel. Page2 does the following:
setACookie();
Session.get().info("blah");
setResponsePage(Page1.class);
The problem I have is that "blah" is never displayed in the feedback
panel of Page1. I stepped in the request processing code and found that
setResponsePage() actually renders the full current page before throwing
that away and issuing a 302 redirect. During this first (unused)
rendering of Page2, its feedback panel consumes all the session
messages. After the client follows the 302 and requests Page1, there are
no more session messages to display.
Instead of setResponsePage, I can use a RestartResponseException to
redirect to Page1 and the session messages will then be displayed on
Page1 because Page2 is never rendered. However this has the important
downside of also throwing away all header information (e.g. cookies like
setACookie() above).
Is there a way to both set a cookie and display the session message on
the response page?
Bonus!
I'm also wondering why, when setResponsePage() is used, the current page
is still rendered. I can think of 3 reasons why this should be avoided:
1-Performance; it's wasteful to render components to discard them right
away
2-Components hierarchy; even if setResponsePage() is used in a page
constructor (e.g. when redirecting depending on page parameters), since
the page is rendered, all of its components or some substitutes must be
added to the page. Otherwise Wicket will throw a missing component
exception in dev mode.
3-My use case; feedback messages registered in the session can be
swallowed by a feedback panel in the thrown away page rendering.
Of course, I definitely don't have the complete picture and am just now
making some sense of how Wicket handles redirects and responses.
Regards,
Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@.apache
For additional commands, e-mail: users-help@.apache
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/setResponsePage-swallows-my-session-feedback-messages-tp4650274p4650278.html
Sent from the Users forum mailing list archive at Nabble.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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
