Re: "It is a better practice to push changes to state rather than pull"
correct. an instance of a component can live through multiple iterations of data. lets say we override isVisible(). there are two problems: 1) the implementation MUST return consistent data, not only during processing of the same request, but also during the processing of the next callback. example: during render link's isVisible() returns TRUE. user clicks a link, during the processing of the callback request isVisible() now returns FALSE. this inconsistency causes wicket to think that there is a security violation since the user somehow managed to click an invisible link. by pushing the value in onConfigure() via setVisible() the value remains consistent until the next render. 2) these kinds of methods are called many times during request processing so the code inside must be simple. if visibility depends on a database query and you put this into isVisible() that query may run twenty times during the request. not very performant. by putting the query into onConfigure() you are guaranteed it will only be executed once per request. so this is component state. data, on the other hand, is different. lifecycle of a component and data doesnt match. components can live longer then data is valid, so it is necessary to always pull fresh data. -igor so for component state it is better to push using setters then overriding getters (since wicket can call getters many times during a request and running the logic that produces On Mon, Apr 16, 2012 at 11:44 AM, Andrew Geery wrote: > In the Javadoc for the Component#onConfigure() method, it states (in a > paragraph dealing with setting whether a component is visible and/or > enabled): "It is a better practice to push changes to state rather than > pull." [ > http://wicket.apache.org/apidocs/1.5/org/apache/wicket/Component.html#onConfigure() > ]. > > My reading of this sentence is that it is contrasting state change, where > changes should be pushed to the component, with data change, where changes > are pulled by the component from the model (i.e, change the model, not the > component). > > Does that sound correct? Are there state changes other than being visible > and being enabled that should be done in onConfigure? > > Thanks > Andrew - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: "It is a better practice to push changes to state rather than pull"
I'm no Wicket expert, but as a general rule it's almost always better to be notified of an event or state change than to constantly poll for it (think of the child in the back seat on a long trip constantly asking "Are we there yet?") From: Andrew Geery To: users@wicket.apache.org Date: 04/16/2012 01:45 PM Subject: "It is a better practice to push changes to state rather than pull" In the Javadoc for the Component#onConfigure() method, it states (in a paragraph dealing with setting whether a component is visible and/or enabled): "It is a better practice to push changes to state rather than pull." [ http://wicket.apache.org/apidocs/1.5/org/apache/wicket/Component.html#onConfigure() ]. My reading of this sentence is that it is contrasting state change, where changes should be pushed to the component, with data change, where changes are pulled by the component from the model (i.e, change the model, not the component). Does that sound correct? Are there state changes other than being visible and being enabled that should be done in onConfigure? Thanks Andrew ** This email and any attachments may contain information that is confidential and/or privileged for the sole use of the intended recipient. Any use, review, disclosure, copying, distribution or reliance by others, and any forwarding of this email or its contents, without the express permission of the sender is strictly prohibited by law. If you are not the intended recipient, please contact the sender immediately, delete the e-mail and destroy all copies. **
"It is a better practice to push changes to state rather than pull"
In the Javadoc for the Component#onConfigure() method, it states (in a paragraph dealing with setting whether a component is visible and/or enabled): "It is a better practice to push changes to state rather than pull." [ http://wicket.apache.org/apidocs/1.5/org/apache/wicket/Component.html#onConfigure() ]. My reading of this sentence is that it is contrasting state change, where changes should be pushed to the component, with data change, where changes are pulled by the component from the model (i.e, change the model, not the component). Does that sound correct? Are there state changes other than being visible and being enabled that should be done in onConfigure? Thanks Andrew