> i'm not sure what i think about this yet. can you show us the
> exact code modifications and use cases you have coded up?
> (boiled down to the important parts, if possible)
Ok, here's the changed bits you requested. Only 3 Java classes need
minor changes in the framework:
[I added the deferred init to WebPage but a more simpler approach is to
add the auto init mechanism to Page to avoid the need for casting.
Option: You could make the mechanism switchable via an application
setting so that existing code and test cases work in the same way as
they do now]
RequestCycle.java
public final void setResponsePage(final Page page)
{
// CJC 20070329 - added to auto init WebPages to allow
// getVariation to work properly
if ( page instanceof WebPage )
{
WebPage webPage = (WebPage)page;
if ( !webPage.isInitialized() )
webPage.commonInit();
}
IRequestTarget target = new PageRequestTarget(page);
setRequestTarget(target);
}
WebPage.java
// CJC 20070329 - defer commonInit till after complete
construction
/** true when the page has been initialized */
private boolean initialized = false;
/**
* Returns the initialization state. This is used by other parts
of
* the framework that will automatically call commonInit on
* uninitialized pages
*/
public boolean isInitialized()
{
return initialized;
}
public void commonInit()
{
// CJC 20070329 - defer commonInit till after
// complete construction
initialized = true;
...
}
+remove the commonInit calls from WebPage constructors
BookmarkablePageRequestTarget.java
private final Page getPage(RequestCycle requestCycle)
{
if (page == null && pageClass != null &&
!requestCycle.getRedirect())
{
page = newPage(pageClass, requestCycle);
// CJC 20070329 - added to auto init WebPages to
allow
// getVariation to work properly
if ( page instanceof WebPage )
{
WebPage webPage = (WebPage)page;
if ( !webPage.isInitialized() )
webPage.commonInit();
}
}
return page;
}
In terms of use cases they're basically our own app plus all the wicket
test cases. Three test cases required initialization to be performed in
an overridden commonInit instead of the constructor to work - which is
standard for most OO frameworks of any kind, not just UI frameworks
(MFC::createWindow, OWL::SetupWindow) - you just don't want to be
playing with partially constructed objects.
> also, it would be good if you could explain how this solves any
problems
> other than getVariation().
getVariation is the biggy at the moment for me but I'm sure as more
users adopt wicket they'll come up with similar scenarios that highlight
this problem. It's feasible to come up with scenarios that don't even
involve framework features but rather, a user's own WebPage derived
class hierarchy.
This example will cause problems doing initialization in the
constructors:
class BasePage
{
public BasePage(params)
{
addTitleComponent();
}
public void addTitleComponent()
{
calls getTitle() to get text of the title and creates a
Label
}
public abstract String getTitle();
}
class MyPage extends BasePage
{
String title = null;
public MyPage(params)
{
title = use params to lookup a particular
object in database andget its name
}
// !! this gets called before the constructor has initialized
title !!
public String getTitle() { return title; }
}
I trust that's informative enough to help you guys make a good decision
on how to deal with this but if you need anything else please let me
know.
-------------------------------------------------------------------------
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
