Creating Clearer Method Names & Concepts

[Richard Bair]

That is correct. Essentially, the property is not invalid when it changes, only when it *might* have changed (since determining the value of the binding might require the resolution of some arbitrarily complicated graph of bindings, and would therefore be expensive to do eagerly). It means, that the value is unknown and requires recomputation.

An InvalidationListener therefore is notified whenever a property becomes invalid, vs when we know the value has actually changed.

I believe that when a ChangeListener is installed, we will figure out whether the thing has changed immediately (making it eager) and send notification.

I tend to always use Invalidation listeners because the method signature is shorter ;-). Also, unless I explicitly read the value in the listener, I won't cause it to be recomputed (but if I do read it in the listener, then of course that is what I wanted to do, so no harm done).

I can't vouch for the names on the Axis, I don't remember those.

Richard

On Nov 2, 2012, at 11:20 AM, Tom Eugelink <tbee at tbee.org> wrote:

> Oh! Let me try to explain that (and see if I got it right).
> 
> The bind is lazy, so when a property changes all bound properties are made invalid (this is when the Invalidation event is fired), but they are not recalculated. Only when the getter is executed, that property really is recalculated (with all kinds of performance cascading things going on) and then new value is known (this is when the Changed event is fired).
> 
> Have I got it right?
> 
> Tom
> 
> 
> 
> On 2012-11-02 19:14, Mark Fortner wrote:
>> I still find myself tripping over the names of methods or concepts in the
>> JavaFX API -- where the API says "X", but only after you dig into the
>> documentation do you discover that it really means Y.
>> 
>> For example, property "Invalidation" doesn't really communicate what the
>> code is actually doing.  The property isn't invalid, it's value has never
>> been validated (we don't yet have that concept in the API), so how can the
>> property be "invalid"? All that's really indicated is that the property
>> value has been changed -- although the subtle distinction between
>> InvalidationListener and ChangeListener is lost on me and I always use a
>> ChangeListener.
>> 
>> At some point when we have a validation framework for JavaFX, how will the
>> concomitant method calls that come with that framework, play out with the
>> existing method calls. There will probably be a lot of head scratching
>> going on.
>> 
>> And there's the documentation for *Axis.toNumericValue*, and *
>> Axis.toRealValue*:
>> 
>> http://docs.oracle.com/javafx/2/api/javafx/scene/chart/Axis.html#toNumericValue(T)
>> 
>> http://docs.oracle.com/javafx/2/api/javafx/scene/chart/Axis.html#toRealValue(double)
>> 
>> Granted, "All axis values must be representable by some numeric value." But
>> what I really want to know is are we translating from user space
>> coordinates to data space coordinates? Or vice-versa?  What is a "real
>> value" and what is a "numeric value"? Aren't all values in an XY chart
>> numbers?
>> 
>> And why is that if I'm translating from user space to data space that I
>> still need to take into account the width of the Y-Axis?  Shouldn't I be
>> able to get coordinates relative to the chart's content space?
>> 
>> 
>> Cheers,
>> 
>> Mark
>