You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Andrew Geery <an...@gmail.com> on 2012/04/16 20:44:56 UTC

"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

Re: "It is a better practice to push changes to state rather than pull"

Posted by Igor Vaynberg <ig...@gmail.com>.
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 <an...@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


Re: "It is a better practice to push changes to state rather than pull"

Posted by "Richard W. Adams" <RW...@UP.COM>.
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 <an...@gmail.com>
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.
**