<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Martin -<br>
<br>
I don't find it especially concerning that stateful/transient
components accessors look slightly different, though I am open to your
recommendation that we provide symmetry here. However, I am concerned
that providing direct access to the TransientStateHelper outside of the
component (ie. via a public getTransientStateHelper() method) is a
(minor) violation of encapsulation - ie. no code other than the
component itself needs to know that the component happens to delegate
transient state management to a TransientStateHelper. Perhaps a
solution that would satisfy both of our concerns would be public
get/putTransient() on UIComponent and protected
getTransientStateHelper().<br>
<br>
Though if we've got public get/putTransient() on UIComponent, I still
wonder how much value is added by introducing the TransientStateHelper
concept - ie. seems like component authors would be able to use the
get/putTransient() APIs with relative ease. <br>
<br>
I am also wondering whether anyone other than UIComponent is going to
implement TransientStateHolder - and whether any code will ever
interact with this contract (as opposed to interacting with the
UIComponent methods).<br>
<br>
Andy<br>
<br>
On 10/22/10 4:26 PM, Martin Marinschek wrote:
<blockquote
cite="mid:AANLkTikcaKozqeOWe57NwzD6oneKZWKwun4WSYB935r9@mail.gmail.com"
type="cite">
<pre wrap="">Hi,
my concern that stateful and transient component getters/setters look
different is not relevant to you?
I am just thinking that users might be confused.
best regards,
Martin
On 10/22/10, Blake Sullivan <a class="moz-txt-link-rfc2396E" href="mailto:blake.sullivan@oracle.com"><blake.sullivan@oracle.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> Since we can always add the TransientStateHelper later if we need it,
we shouldn't have it in the specification for this release.
-- Blake Sullivan
On 10/22/10 4:25 AM, Andy Schwartz wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>