Re: new feature in trunk and branch: Component#onConfigure()

2010-07-21 Thread Johan Compagner
can we now deprecate  protected boolean callOnBeforeRenderIfNotVisible() ??

because you could do it now in onConfigure right?
I hate multiply things do do the same thing :(

On Wed, Jul 21, 2010 at 07:05, Igor Vaynberg igor.vaynb...@gmail.com wrote:
  protected boolean callOnBeforeRenderIfNotVisible()

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: new feature in trunk and branch: Component#onConfigure()

2010-07-21 Thread Igor Vaynberg
its already deprecated

-igor

On Tue, Jul 20, 2010 at 11:46 PM, Johan Compagner jcompag...@gmail.com wrote:
 can we now deprecate  protected boolean callOnBeforeRenderIfNotVisible() ??

 because you could do it now in onConfigure right?
 I hate multiply things do do the same thing :(

 On Wed, Jul 21, 2010 at 07:05, Igor Vaynberg igor.vaynb...@gmail.com wrote:
  protected boolean callOnBeforeRenderIfNotVisible()

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: new feature in trunk and branch: Component#onConfigure()

2010-07-21 Thread vineet semwal
very nice feature,
 thank you !!

On Wed, Jul 21, 2010 at 10:35 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote:

 another new callback added to 1.4/trunk that is aimed at making life
 easier when managing component states such as visibility, enabled,
 etc.

/**
 * Called once per request on components before they are about to be
 rendered. This method
 * should be used to configure such things as visibility and enabled
 flags.
 * p
 * Overrides must call {...@code super.onInitialize()}, usually before
 any other code
 * /p
 * p
 * NOTE: Component hierarchy should not be modified inside this
 method, instead it should be
 * done in {...@link #onBeforeRender()}
 * /p
 * p
 * NOTE: Why this method is preferrable to directly overriding
 {...@link
 #isVisible()} and
 * {...@link #isEnabled()}? Because those methods are called multiple
 times even for processing of
 * a single request. If they contain expensive logic they can slow
 down the response time of the
 * entire page. Further, overriding those methods directly on form
 components may lead to
 * inconsistent or unexpected state depending on when those methods
 are called in the form
 * processing workflow. It is a better practice to push changes to
 state rather than pull.
 * /p
 * p
 * NOTE: If component's visibility or another property depends on
 another component you may call
 * {...@code other.configure()} followed by {...@code 
 other.isVisible()}
 as
 mentioned in
 * {...@link #configure()} javadoc.
 * /p
 * p
 * NOTE: Why should {...@link #onBeforeRender()} not be used for this?
 Because if visibility of a
 * component is toggled inside {...@link #onBeforeRender()} another
 method needs to be overridden
 * to make sure {...@link #onBeforeRender()} will be invoked on
 ivisible
 components:
 *
 * pre
 * class MyComponent extends WebComponent
 * {
 *  protected void onBeforeRender()
 *  {
 *  setVisible(Math.rand() gt; 0.5f);
 *  super.onBeforeRender();
 *  }
 *
 *  // if this override is forgotten, once invisible component
 will
 never become visible
 *  protected boolean callOnBeforeRenderIfNotVisible()
 *  {
 *  return true;
 *  }
 * }
 * /pre
 *
 * VS
 *
 * pre
 * class MyComponent extends WebComponent
 * {
 *  protected void onConfigure()
 *  {
 *  setVisible(Math.rand() gt; 0.5f);
 *  super.onConfigure();
 *  }
 * }
 * /pre
 */
protected void onConfigure()
{

}

/**
 * Triggers {...@link #onConfigure()} to be invoked on this component
 if
 it has not already during
 * this request.
 * p
 * This method should be invoked before any calls to {...@link
 #isVisible()} or
 * {...@link #isEnabled()}. Usually this method will be called by the
 framework before the
 * component is rendered and so users should not need to call it;
 however, in cases where
 * visibility or enabled or other state of one component depends on
 the state of another this
 * method should be manually invoked on the other component by the
 user. EG to link visiliby of
 * two markup containers the following should be done:
 *
 * pre
 * final WebMarkupContainer source=new WebMarkupContainer(a) {
 *  protected void onConfigure() {
 *setVisible(Math.rand()0.5f);
 *  }
 * };
 *
 * WebMarkupContainer linked=new WebMarkupContainer(b) {
 *  protected void onConfigure() {
 *  source.configure(); // make sure source is
 configured
 *  setVisible(source.isVisible());
 *  }
 * }
 * /pre
 *
 * /p
 */
public final void configure()
{
if (!getFlag(FLAG_CONFIGURED))
{
onConfigure();
setFlag(FLAG_CONFIGURED, true);
}
}

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




-- 
regards,
Vineet Semwal


Re: new feature in trunk and branch: Component#onConfigure()

2010-07-21 Thread Erik van Oosten

Excellent!

Op 21-07-10 07:05, Igor Vaynberg wrote:

another new callback added to 1.4/trunk that is aimed at making life
easier when managing component states such as visibility, enabled,
etc.


   



--
Erik van Oosten
http://www.day-to-day-stuff.blogspot.com/


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: new feature in trunk and branch: Component#onConfigure()

2010-07-20 Thread Ernesto Reinaldo Barreiro
Igor,

Thanks for the new feature!


        /**
         * Called once per request on components before they are about to be
 rendered. This method
         * should be used to configure such things as visibility and enabled 
 flags.
         * p
         * Overrides must call {...@code super.onInitialize()}, usually before
 any other code
         * /p

Should not this be{...@code super.onConfigure()}?

Cheers,

Ernesto

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org