ah, sorry. this is the code i take it. just not in response to my original
post (at least on nabble).
Chris Colman wrote:
>
>> 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
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
>
--
View this message in context:
http://www.nabble.com/Lifecycle-issue-with-getVariation-tf3476789.html#a9747200
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
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
