there is a reason why some of the stuff is done where it is. now, 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.
juergen are you reading with us?
-igor
On 3/27/07, Chris Colman <[EMAIL PROTECTED]> wrote:
I went ahead and implemented these changes in my copy of the wicket
source code and now I can specify a variation at the Page level (never
been able to do that before!) without causing a NPE. It works very
nicely indeed.
> what about pages that are constructed with the new operator?
I mainly use bookmarkable pages and so my pages are constructed (and now
commonInit'd) by the DefaultPageFactory - result: I didn't have to
change any of my own code to get my getVariation working properly.
I get the feeling that error pages don't get instantiated via the
DefaultPageFactory and so I will need to find out where they are new'ed
so I can change the wicket source to call commonInit on them also.
The HelloWorld example just returns the page Class to use - ie., doesn't
do new MyPage(). So presumably the DefaultPageFactory is doing the
initialization for that one also. So HelloWorld would work ok with the
improved initialization lifecycle.
> the users then have to explicitly call commoninit() from their
> constructors?
Not necessarily. After you create a page explicitly yourself don't you
have to hand it on to 'something else' before you can use it to render a
page? That 'something else' could call a boolean isInitialized() method
and call commonInit if not already initialized. There's plenty of ways
to make this work well so users don't have to call commonInit
themselves.
> i think that is horrible.
It would be horrible if users had to do it explicitly but I'm sure there
are ways (above example) to make it automagically done for the user so
they don't have to call commonInit themselves.
> what we need to do is somehow delay the getvariation() until
> render time.
Well, that sounds like it will fix the getVariation problem but how many
other problems are going to give us a world of pain in the future
because of the use of partially constructed WebPage objects?
The other problem is that commonInit is doing a whole lot of stuff with
the markup and it needs to know the variation to get the correct markup
- I don't see how you can defer getVariation unless you defer the whole
markup analysis code that follows the call to getVariation as well... I
ended up deferring the whole commonInit call but you might be able to
carve out a smaller portion of code to defer.
-------------------------------------------------------------------------
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
-------------------------------------------------------------------------
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
