On 08 Mar 2011, at 17:54, Carl-Eric Menzel wrote: > > > However, there are much better arguments than existing codebase for > still allowing constructors. First, constructors are natural places to > do stuff like that. Yes, they have limitations, and yes, PostConstruct > exists for a reason, but that doesn't render constructors obsolete.
Your constructors are the perfect place to initialize your instance, at least at the level of your constructor's type. Build all your instance variables there, handle your page parameters, and that stuff. Just like EJBs, you should be careful about how much interaction you do beyond your object's scope within the constructor. Your component doesn't have a hierarchy, getPage() cannot be accessed, none of your subclass constructors have been invoked and therefore your instance is not properly initialized and ready for use. You really shouldn't be doing anything in your constructor that is NOT related to initializing your constructor type's instance variables. Touch anything else, invoke any methods, and you are opening pandora's box. It's important to understand *what* constructors are a natural place for. > Second, if you need to use any kind of parameters for stuff you do in > onInitialize, you *must* store them in instance variables, even if you > need them just once and could have long let them be garbage collected. > Going purely post-construct would be a very bad idea for this reason. Sorry? Parameters? You mean arguments to your components' constructor? Of course, but you really shouldn't ever need these in onInitialize if they're not state. And yes, your component's state belongs in its instance variables. If this is an issue, could you enlighten me? --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
