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<
[hidden email]> 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
>>
>