Guess it comes down to a preference of constructor vs setter injection.
I don't see a big problem with exposing the initPage(Page) method on
Context. Perhaps the name initPage might be confused with onInit, so we
should think about whether initPage is the right name. How about
configurePage? We should also give some thought on what will happen if a
user accidentally invokes configurePage after a createPage call.
Keep in mind that a no-arg Page constructor is still needed if the Page
is to be accessed from the browser, since Click won't know how to
construct a Page which accepts arguments in its constructor.
Finn, perhaps you can open a JIRA and attach your patch?
kind regards
bob
Malcolm Edgar wrote:
Hi Finn,
What about setting the Page arguments as properties in your page?
MyPage page = getContext().createPage(MyPage.class);
page.setSecure(true);
setForward(page);
regards Malcolm Edgar
On Mon, Aug 31, 2009 at 6:37 AM, Finn Bock<bck...@gmail.com> wrote:
Hi,
I wonder if it isn't possible to relax the restriction that page
instances passed to setForward() must be created by
getContext().createPage(MyPage.class);
Page dependencies must of course still be injected, but it could be
done as a separate step:
MyPage page = new MyPage(true);
getContext().initPage(page);
setForward(page);
The fictional method "initPage()" will perform the injection of page
dependencies currently found in ClickServlet.initPage():
activatePageInstance
setHeaders
setPath
auto binding
processPageRequestParams
This way it is possible to use arguments in the constructor to forwarded pages.
If such a change is interesting, I would be happy to write a patch.
regards,
Finn
