Hi,
Here is my later response.
I see two ways to solve this:
1) Use setResponsePage(pageInstance) as I described in my previous response:
setMyCookie();
PageB pageB = new PageB();
pageB.info("some text");
setResponsePage(pageB);
This way the feedback is associated with a component (pageB) and wont
be rendered when PageA is rendered.
The drawback is that this way you will get a url like 'wicket/page?42'
instead of the nice looking one (e.g. /customers/12)
2) the second way is to use non-resetting RestartResponsePage
I've rolled this out several months ago for our app:
public class NonResettingRestartException extends ReplaceHandlerException {
public NonResettingRestartException(final Class<? extends Page<?>>
pageClass, final PageParameters params, final RequestCycle cycle) {
super(createRequestHandler(pageClass, params), true);
Response response = cycle.getResponse();
if (response instanceof IMetaDataBufferingWebResponse) {
IMetaDataBufferingWebResponse bufferingWebResponse =
(IMetaDataBufferingWebResponse) response;
bufferingWebResponse.writeMetaData((WebResponse)
cycle.getOriginalResponse());
}
}
private static IRequestHandler createRequestHandler(Class<?
extends Page<?>> pageClass, PageParameters params) {
return new RenderPageRequestHandler(new
PageProvider(pageClass, params));
}
}
and use it:
setMyCookie();
throw new NonResettingRestartException(PageB.class, params);
I guess you will prefer option 2)
See inline below.
On Fri, Jun 29, 2012 at 12:11 AM, Bertrand Guay-Paquet
<ber...@step.polymtl.ca> 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.
I think this is a good opportunity for an improvement! Please file a
ticket and we will investigate it.
Ajax support in Wicket works using this way: a
ListenerInterfaceRequestHandler (LIRH) is executed and
AjaxRequestHandler(/Target) (ART) is scheduled immediately and passed
to the callback function (e.g. onClick(AjaxRequestTarget)) so the user
code can use it and add components to it. Later when LIRH is ready
Wicket starts ARA which just renders whatever is already collected in
it (JavaScript and components) to <ajax-response>.
The comments in WebPageRenderer (related to WICKET-4358) also say that
a IRequestHandler can be scheduled during rendering, but I see no
reason why to render at all if there is already a scheduled
IRequestHandler before starting the rendering.
>
> Regards,
> Bertrand
>
> ---------------------------------------------------------------------
> 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
