>> So to summarize my rant: >> >> -1 for removing the ability to use add inside a constructor. >> +0 for improving the handling of oninitialize >> +1 for improving the documentation on the lifecycle of components and >> the event chain called during processing [2] > >I assume that means you don't care if 3218 is marked as won't fix and >onInitialize remains overridable by those that choose to use it.
It depends if the current code calls onInitialize as a side effect of calling page#add. If so then it would be good to change that so that onInitialize is called by the framework after page contruction has completed. The operation of onInitialize would then be nice a 'pure': that is, it is never invoked during construction - even if someone calls page#add in a constructor. > >Documentation is a good enough alternative when there is an unresolved >issue that only occurs in rare cases. So yes, document it, and let those >that want to use onInitialize do so. > >I never claimed using constructors will make your webapps eat your young. >I simply outlined the pros and cons of each approach and argued the design >advantages of not touching your components from outside wicket lifecycle >methods. >--------------------------------------------------------------------- >To unsubscribe, e-mail: [email protected] >For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
