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
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
