> there is a reason why some of the stuff is done where it is. now, I believe that with the minor change that I have made everything is still being done in the exact same order so there should be no consequences of this change. It's just that all the stuff done in commonInit is now being slightly deferred so that it uses completely constructed objects instead of partially constructed objects - that can't be a bad thing can it?
I've certainly had no trouble with my page creation and usage with this change - in fact things that I couldn't get to work before now work perfectly! Source changes: I've taken a more inclusive, simpler approach that changes RequestCycle and BookmarkablePageRequestTarget instead of changing the DefaultPageFactory. This means absolutely no explicit calling of the commonInit method by users. I had to change 3 pages in the test cases so that they do their init in commonInit instead of the constructor and all test cases now succeed. I can make available a copy of my modified 1.2.5 source with all changes clearly marked if any one is interested. Java is interesting in that virtual methods appear to 'semi' work on partially constructed objects (which can make you think everything is fine). C++ on the other hand did not allow the virtual function mechanism to work properly until objects were completely constructed. So prior to constructor completion, for non abstract methods, C++ just calls the current class' method instead of the most derived class' method and, for abstract methods, it could result in the strange but extremely useful 'call of pure virtual (abstract) function' error. When you got that error you knew you were dancing with the devil. I think Java lets you keep on dancing... > im not sure there is a reason for the markup loading for bodcontainer, > we might be able to do that lazily when getbodycontainer() is called. Other frameworks (eg,. Echo2) handle this partial construction problem by automatically calling an init method on the class whenever you add it to the system after instantiation. The user doesn't need to (and shouldn't) explicitly call init() as it's done for them. They can even override init() if they want to but must first call super.init() prior to doing any of their own initialization work. In fact this is the exact pattern of initialization that you have implemented for wicket's WebApplication. It seems to make sense to me that the same pattern would apply to WebPage. > juergen are you reading with us? > > -igor ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
