Feature Requests item #1408671, was opened at 2006-01-18 01:39
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=684978&aid=1408671&group_id=119783
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: 1.2
Status: Open
Priority: 5
Submitted By: Igor Vaynberg (ivaynberg)
Assigned to: Nobody/Anonymous (nobody)
Summary: redirect to page exception
Initial Comment:
there are a few problems with setting response pages
and authentication currently.
first:
calling setResponsePage() from a constructor of another
page should not create the calling page, abort the
process, and reset the request cycle with the new page.
instead, the calling page gets constructed, added to
the pagemap, and then the request cycle resets. both
these things are a waste.
it also makes it difficult for us to find the actual
request target for a bookmarkable page since
setresponsepage() is expected to work from a
constructor of another page.
second:
authentication sucks. checkaccess is called too late,
and i cannot do the following in my basesecurepage
class BaseSecurePage extends WebPage() {
public BaseSecurePage() {
if (MySession.get().getUser()!=null) {
setResponsePage(LoginPage.class);
}
}
}
this sucks, because what i really want to do is to
interrupt the creation of this page, but i cannot do
that. if the subclass expects to be authenticated it
might try to get the user from the session and fail
because the base page cannot prevent it from executing.
so currently its impossible to encapsulate
authentication in a base page.
a solution for this would be to have a
RedirectToPageException. this has a good semantic of
unrolling the stack all the way to the request
processor and will abort creation of the throwing page.
yes this is not exactly an /exceptional/ situation so
using an exception might not be one hundred percent
desirable, but until java offers an equivalent semantic
through something else we dont really have a choice.
yes exceptions are expensive to create. to work around
this we can use a singleton instance of the exception,
and carry the page information through a call to
setResponsePage. we dont like the stacktrace info so
singleton should be ok. some people are against reusing
exception objects because for some reason it is
considered a no-no, but there is nothing /wrong/ with
it. just because it is not widely used doesnt mean it
is at all outside the box! even sun says it is /ok/ to
reuse exception objects and even precreate them:
http://java.sun.com/developer/JDCTechTips/2003/tt0422.html#2
so the way i see this working is to add:
class ResponsePageInterrupt extends Throwable {
public static final ResponsePageInterrupt
INSTANCE=new ResponsePageInterrupt();
public ResponsePageInterrupt() {}
}
public void Page.setImmediateResponsePage(Page/Class
param) {
setResponsePage(param); // records what page we want
to redirect to in the request cycle
throw(ResponsePageInterrupt.INSTANCE); // causes the
reset of the request cycle to the new redirect page
}
we keep the interrupt package private as an
implementation detail, or we can make it public - i
dont know what the best choice is yet.
names of all these things are up for grabs.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=684978&aid=1408671&group_id=119783
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Wicket-develop mailing list
Wicket-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-develop
