Hey Martin -
Here is how I was thinking about this...
With transient properties, we have two types of use cases:
1. Components storing transient attributes on themselves.
2. External classes storing transient attributes on components.
The use case you mention below falls under #1.
In earlier threads there were a references to use cases that fall under
#2 (eg. a renderer setting a transient property on a component).
If we go with the original API proposal of adding public methods to
UIComponent, ie:
- public Object getTransient(Object key)
- public Object putTransient(Object key, Object value)
We have everything we need to address #1 and #2. Your sample below can
be rewritten as:
Double getCalculatedWeight() {
return (Double) getTransient(PropertyKeys.weight, false);
}
void setCalculatedWeight(Double weight) {
putTransient(PropertyKeys.weight, weight);
}
I don't see how adding a new TransientStateHelper contract improves this
situation. That's not to say that we cannot do this. The first patch
that I provided leaves TransientStateHelper in place. Just seems like
added conceptual overhead that might not be necessary.
Andy
On 10/22/10 7:02 AM, Martin Marinschek wrote:
Hi Andy,
maybe I am missing something here, but isn't the normal use-case for
this a new component which adds a transient attribute?
something like: calculatedWeight. This should of course be exposed via
the API of the component - so there should be a:
Double getCalculatedWeight();
void setCalculatedWeight(Double weight);
And my point was that the implementation of these stateless getters
and setters should look similar to the stateful version.
What I would do:
Double getCalculatedWeight() {
return (Double) getTransientStateHelper().get(PropertyKeys.weight, false);
}
void setCalculatedWeight(Double weight) {
getTransientStateHelper().put(PropertyKeys.weight, weight);
}
Could TransientStateHelper not be an alternative implementation of the
StateHelper interface?
best regards,
Martin