Ok now I understand! What you suggest is more or less what I mentioned
in the first email. RestartResponseException does indeed halt rendering
of Page2 which causes the flash message to be displayed on Page1.
I guess I could find a way to pass as page parameters of Page1 the
cookie and set it there, but that's a bit of a hassle. In my case, the
actual cookie setting code is far removed from Page2's constructor; I
simplified the code a lot in my original email.
p.s. Hmm I guess this thread shows that I should have chosen meaningful
names for my page classes! Even I need to concentrate to make sure I
don't mess it up...
On 29/06/2012 10:02 AM, Ian Marshall wrote:
Sorry,
"raw" HTML tag content did not make it to the E-mail....
I meant:
If you use
Session.get().info("blah");
and then one of
throw new RestartResponseException(Page1.class, PageParameters params);
throw new RestartResponseException(new Page1(...));
in your Page2 constructor you should be able to pass (your cookie?) data to
your Page1, and you will see by trial and error whether your flash message
makes it to Page1 or not (but without your cookies).
You're better off listening to Martin G: he knows what he is talking about
;)
Bertrand Guay-Paquet wrote
Hi Ian,
I'm sorry, I don't understand. Perhaps some parts of your message didn't
make it to the mailing list? (see "If you use" and "and then one of").
On 29/06/2012 9:39 AM, Ian Marshall wrote:
Hi Bertrand,
If you use
and then one of
in your Page2 constructor you should be able to pass (your cookie?) data
to
your Page1, and you will see by trial and error whether your flash
message
makes it to Page1 or not.
Regards,
Ian
Bertrand Guay-Paquet 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-unsubscribe@.apache
For additional commands, e-mail: users-help@.apache
---------------------------------------------------------------------
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-tp4650274p4650284.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@.apache
For additional commands, e-mail: users-help@.apache
---------------------------------------------------------------------
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-tp4650274p4650287.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
