wicket-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Vaynberg <igor.vaynb...@gmail.com>
Subject Re: "It is a better practice to push changes to state rather than pull"
Date Mon, 16 Apr 2012 19:30:29 GMT
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.


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 <andrew.geery@gmail.com> 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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

View raw message