arrghh :)
in the onBeginRequest() you are already responding a page... !
You shouldn't redirect in that one.
If you want to stop responding a page you should override checkAccess()
There is as far as i know the only place where you should call
redirectTo() or redirectToInterceptPage()
redirectToInterceptPage does store the page where it would go to before
redirecting to the page the user should go to first
then on the that page (if the user has logged in) you can ask the page
map what the url was where the user wanted to go to
and redirect again. (call getPage().continueToOriginalDestination())
so i think you should use redirectTo as little as possible
only use it in for example checkAccess() of page.
And there you have to choose do i want to use the original destination
again then use redirectToInterceptPage
else always use setResponsePage() (the homepage constructor problem
needs to be fixed.... )
johan
Matej Knopp wrote:
I think maybe for now it would be enough to mention in javadoc
something like if you want to do redirect from page contructor use the
redirectTo instead of setResponsePage.
btw. setResponsePage doesn't work in onBeginRequest too. One hack to
get it work coud be to check in setResponsePage what listener and
target object is specified, and if it is IRedirectListener and target
object is a page (not a component) or no listener is specified at all
(page creation), setResponsePage would just call redirectTo. But this
may just be too ugly :)
-Matej
Eelco Hillenius wrote:
Matej Knopp wrote:
It doesn't seem to be inconsistent to me.
SetResponsePage sets a page to respond. But IMHO to respond you need
an action first. In constructor, there's no such action. When you
click on a link or submit a form, it is an action. So
SetResponsePage works.
But this is just as I see it. It's possible that it's meant
otherwise and it's just a bug.
Maybe it would be better if SetResponsePage worked this well. But I
think that it's worth implementing only if it's not a big
change/hack to wicket action/request/response handling.
Yeah. And that's exactly where the problem is... it is difficult to
implement without a hack, as the response page is set after the
constructor is called (quite natural as we can't set the page when it
is not even constructed...).
I'll leave it for now then, though I want to build in a little bit
more debugging.
Eelco
-Matej
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
