https://issues.apache.org/jira/browse/WICKET-432
-igor
On 3/28/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
On 3/28/07, Chris Colman <[EMAIL PROTECTED]> 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?
introducing a required post-construct init method is hardly a minor
change. while this works well for you because you mostly use bookmarkable
pages it wont hold for normal apps where bookmarkable pages are a minority.
and there are in fact consequences to your change. i can no longer do
getBodyContainer().addOnLoadModifier(...) from the constructor of my page.
so where am i to do it now? i need to use that post-construct callback, so
now there are two places where i need to initialize my component - hardly
simple still.
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.
have you also changed all other page-related request targets as well? have
you built safeguards to make sure this method is atomic?
the fact that you had to call this method manually in tests is proof
enough for me that what you propose does not work well.
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...
yes, we are all aware of the fact that it is not a good idea to call
overloaded methods from the parent's constructor. like i said, the problem
is that getvariation() is called as a side effect of something done in the
commoninit method - and that is what needs to be fixed. there shouldnt be a
reason why we need to call getvariation()/load markup at construction time.
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.
yes, but in wicket we prefer constructors. they are in java for a reason
:) i dont know about echo2 but in wicket components are not beans.
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.
webapplication is a "managed" class, so there we didnt really have a
choice. webapplication also does not implement the compound pattern where
such a call has to be cascaded. in short, webapplication and webpage (which
is a component) are very different.
other devs feel free to weigh in. i will create a jira issue for this so
we can track it and think about possible solutions.
-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
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
