can you show us your code?
Chris Colman wrote: > >> 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 > > -- View this message in context: http://www.nabble.com/Lifecycle-issue-with-getVariation-tf3476789.html#a9747169 Sent from the Wicket - User mailing list archive at Nabble.com. ------------------------------------------------------------------------- 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
