Re: final Page.onInitialize()
Hans,
I'm agreeing. I'm just saying that if you start treating the onIniliaze() as
the place to create your components then you are stuck with the same problem
as before:
class MyPage {
MyPage() {
}
* onInitialize() < Using onInitialize in the page doesn't give you
anything, so that is why its 'final'
add(new MyPanel());
}*
}
class MyPanel {
MyPanel() {
log.debug("getPage() = " + getPage()); <= null
add(new Label("id", getString("resKey")); <= does not resolve
}
}
On Thu, Feb 10, 2011 at 2:08 AM, Hans Lesmeister 2 <
hans.lesmeis...@lessy-software.de> wrote:
>
> Hi,
>
>
> Clint Checketts wrote:
> >
> > I don't believe the goal of onInitiallize is to move all component
> > creation
> > from the constructor to onInitialize, since if you are adding the
> > component
> > to the parent in the onInitialize method then you are back to the problem
> > of
> > not being able to call getPage() in your components.
> >
>
> I think it is the opposite: if I create and add components in their
> respective constructors I do not have access to getPage():
>
>
> class MyPage {
> MyPage() {
>add(new MyPanel());
> }
> }
>
> class MyPanel {
> MyPanel() {
>log.debug("getPage() = " + getPage()); <= null
>add(new Label("id", getString("resKey")); <= does not resolve
> }
> }
>
>
> So at least in my panels and other containers I would keep creating
> components in onInitialize(). Is that right?
>
> Overridable factory methods in my base page (which should not be called
> from
> the constructor) are mainly there to create Components, so from where can
> they be called if I can't override onInitialize()? I would not like to go
> back to onBeforeRender and maintain a flag myself.
>
> Cheers
> Hans
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/final-Page-onInitialize-tp3250951p3298712.html
> Sent from the Forum for Wicket Core developers mailing list archive at
> Nabble.com.
>
Re: final Page.onInitialize()
Hi,
Clint Checketts wrote:
>
> I don't believe the goal of onInitiallize is to move all component
> creation
> from the constructor to onInitialize, since if you are adding the
> component
> to the parent in the onInitialize method then you are back to the problem
> of
> not being able to call getPage() in your components.
>
I think it is the opposite: if I create and add components in their
respective constructors I do not have access to getPage():
class MyPage {
MyPage() {
add(new MyPanel());
}
}
class MyPanel {
MyPanel() {
log.debug("getPage() = " + getPage()); <= null
add(new Label("id", getString("resKey")); <= does not resolve
}
}
So at least in my panels and other containers I would keep creating
components in onInitialize(). Is that right?
Overridable factory methods in my base page (which should not be called from
the constructor) are mainly there to create Components, so from where can
they be called if I can't override onInitialize()? I would not like to go
back to onBeforeRender and maintain a flag myself.
Cheers
Hans
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/final-Page-onInitialize-tp3250951p3298712.html
Sent from the Forum for Wicket Core developers mailing list archive at
Nabble.com.
Re: final Page.onInitialize()
Hi, That's exactly how I am using onInitialize on Pages / Components - to call overridable factory methods outside of the constructor. So for me: +1 (re-)make onInitialize non final Regards, Daniel On 02.02.2011 11:11, Hans Lesmeister 2 wrote: Hi, After onInitialize was introduced in 1.4.12 we have done a lot of refactoring in a lot of pages to get component-creation out of the constructors and into onInitialize. Especially calling overridable factory methods from a constructor is gone now which we and PMD really appreciate. Carl-Eric Menzel-7 wrote: I think this could be sufficiently guarded by putting a good explanation on onInitialize's javadoc. Besides, by this logic, Component is also incompletely initialized until the moment it gets added to the page. Ack +1 for Carl-Eric's patch Cheers Hans
Re: final Page.onInitialize()
I think onInitialize is playing the role of the Component#addNotify method from awt framework. It is an useful callback to not root components, were they can adjust their sate based on the existing component tree. And if we rename it to onAddedToComponentTree or addNotify as in the awt framework? After doing so we can even recreate the onInitialize method but as a callback for an fully constructed component. The problem about this idea is that we would end up increasing the API, maybe without the need. Anyway I'm 1+ to delay the onInitialize call until the first onConfigure call, because makes sense to provide an callback from a more mature component state. On Tue, Feb 1, 2011 at 2:52 PM, Igor Vaynberg wrote: > apparently some people also use it as a post-construct callback, which > sort of makes sense. for example, to call overridable factory methods, > which you cannot do from the constructor. > > the solution is to delay all calls to oninitialize until just before > the very first call to onconfigure. i have mixed feelings about it > because essentially when instantiating a new page you get an > incomplete/lazy-initialized object and it is hard to have any useful > methods on it that configure it further. > > -igor > > > On Tue, Feb 1, 2011 at 3:35 AM, Pedro Santos wrote: > > onInitialize is only there to provide an place on the component code > where > > you can rely on a path to the page from the component. It is useless > inside > > an page. > > > > On Tue, Feb 1, 2011 at 9:25 AM, tetsuo wrote: > > > >> Overriding onInitialize() on Pages certainly may cause some problems, > >> if you mix adding components there and in constructors in the same > >> class hierarchy, but it will work with some care. I'm using > >> onInitialize() to build Pages, because, in the infrastructure already > >> built in a project I'm working on, I have to instantiate Pages to > >> determine if a link to it is enabled or not. I don't use its > >> 'construction', I don't need components. I just instantiate it to call > >> a method 'hasPermission()' on it. > >> > >> Well, please don't tell me I shouldn't do it, it works and works well. > >> The only problem is that in 1.5 the method is final on Pages. Is there > >> any workaround? Would you consider reverting this change? Or will I > >> have to stay with 1.4 forever? > >> > >> Tetsuo > >> > > > > > > > > -- > > Pedro Henrique Oliveira dos Santos > > > -- Pedro Henrique Oliveira dos Santos
Re: final Page.onInitialize()
I don't believe the goal of onInitiallize is to move all component creation from the constructor to onInitialize, since if you are adding the component to the parent in the onInitialize method then you are back to the problem of not being able to call getPage() in your components. I say keep constructing components in constructors as well as adding them to their parents, and ONLY use onInitialize for initialization logic. The sort of stuff you'd put in onBeforeRender that would only run once. I'm not weighing in on changing Page's onInitialize from final, but I fear if users begin constructing and adding their components in the onInitialize call, then it removes the guarantee from that method that getPage() calls will always function correctly. -Clint On Wed, Feb 2, 2011 at 4:11 AM, Hans Lesmeister 2 < hans.lesmeis...@lessy-software.de> wrote: > > Hi, > > After onInitialize was introduced in 1.4.12 we have done a lot of > refactoring in a lot of pages to get component-creation out of the > constructors and into onInitialize. Especially calling overridable factory > methods from a constructor is gone now which we and PMD really appreciate. > > > Carl-Eric Menzel-7 wrote: > > > > I think this could be sufficiently > > guarded by putting a good explanation on onInitialize's javadoc. > > Besides, by this logic, Component is also incompletely initialized > > until the moment it gets added to the page. > > > > Ack > > +1 for Carl-Eric's patch > > Cheers > Hans > > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/final-Page-onInitialize-tp3250951p3253718.html > Sent from the Forum for Wicket Core developers mailing list archive at > Nabble.com. >
Re: final Page.onInitialize()
Hi, After onInitialize was introduced in 1.4.12 we have done a lot of refactoring in a lot of pages to get component-creation out of the constructors and into onInitialize. Especially calling overridable factory methods from a constructor is gone now which we and PMD really appreciate. Carl-Eric Menzel-7 wrote: > > I think this could be sufficiently > guarded by putting a good explanation on onInitialize's javadoc. > Besides, by this logic, Component is also incompletely initialized > until the moment it gets added to the page. > Ack +1 for Carl-Eric's patch Cheers Hans -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/final-Page-onInitialize-tp3250951p3253718.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
Re: final Page.onInitialize()
On Tue, 1 Feb 2011 08:52:03 -0800 Igor Vaynberg wrote: > apparently some people also use it as a post-construct callback, which > sort of makes sense. for example, to call overridable factory methods, > which you cannot do from the constructor. > > the solution is to delay all calls to oninitialize until just before > the very first call to onconfigure. You have just described both my usecase and the patch I submitted a while ago ;-) > i have mixed feelings about it > because essentially when instantiating a new page you get an > incomplete/lazy-initialized object and it is hard to have any useful > methods on it that configure it further. I understand the mixed feelings. However, I rarely find myself instantiating a Page class manually and then doing anything other than handing it to setResponsePage(). I think this could be sufficiently guarded by putting a good explanation on onInitialize's javadoc. Besides, by this logic, Component is also incompletely initialized until the moment it gets added to the page. In the meantime since the patch mentioned above was rejected, our project went back to doing onBeforeRender with manual guard against repeated post-construct initialization. This works. It has the same drawback of being incomplete for a short duration, and it mixes actual beforeRender stuff with late initialization, which can get confusing. I think onInitialize would at least relocate these things to a clearly visible and obvious spot. The bottom line is, you need to know what you are doing if you do post-construct initialization, no matter where you put that stuff. That said, it could be a more visible spot than onBeforeRender ;-) I'm +0.5 for going with my patch. Pro: - nice to have - makes Page consistent with Component Con: - may break if an uninitialized Page (or Component!) is used carelessly. With Component this problem exists today already, at least until the component is added to its page. With Page it will not break existing code, since Page's onInitialize doesn't work properly at all at the moment. - not having it is not a showstopper Carl-Eric www.wicketbuch.de
Re: final Page.onInitialize()
apparently some people also use it as a post-construct callback, which sort of makes sense. for example, to call overridable factory methods, which you cannot do from the constructor. the solution is to delay all calls to oninitialize until just before the very first call to onconfigure. i have mixed feelings about it because essentially when instantiating a new page you get an incomplete/lazy-initialized object and it is hard to have any useful methods on it that configure it further. -igor On Tue, Feb 1, 2011 at 3:35 AM, Pedro Santos wrote: > onInitialize is only there to provide an place on the component code where > you can rely on a path to the page from the component. It is useless inside > an page. > > On Tue, Feb 1, 2011 at 9:25 AM, tetsuo wrote: > >> Overriding onInitialize() on Pages certainly may cause some problems, >> if you mix adding components there and in constructors in the same >> class hierarchy, but it will work with some care. I'm using >> onInitialize() to build Pages, because, in the infrastructure already >> built in a project I'm working on, I have to instantiate Pages to >> determine if a link to it is enabled or not. I don't use its >> 'construction', I don't need components. I just instantiate it to call >> a method 'hasPermission()' on it. >> >> Well, please don't tell me I shouldn't do it, it works and works well. >> The only problem is that in 1.5 the method is final on Pages. Is there >> any workaround? Would you consider reverting this change? Or will I >> have to stay with 1.4 forever? >> >> Tetsuo >> > > > > -- > Pedro Henrique Oliveira dos Santos >
Re: final Page.onInitialize()
onInitialize is only there to provide an place on the component code where you can rely on a path to the page from the component. It is useless inside an page. On Tue, Feb 1, 2011 at 9:25 AM, tetsuo wrote: > Overriding onInitialize() on Pages certainly may cause some problems, > if you mix adding components there and in constructors in the same > class hierarchy, but it will work with some care. I'm using > onInitialize() to build Pages, because, in the infrastructure already > built in a project I'm working on, I have to instantiate Pages to > determine if a link to it is enabled or not. I don't use its > 'construction', I don't need components. I just instantiate it to call > a method 'hasPermission()' on it. > > Well, please don't tell me I shouldn't do it, it works and works well. > The only problem is that in 1.5 the method is final on Pages. Is there > any workaround? Would you consider reverting this change? Or will I > have to stay with 1.4 forever? > > Tetsuo > -- Pedro Henrique Oliveira dos Santos
