I understand what you are trying to do. I was wondering if a more coarse
grained approach would be preferable, so a central registration of whether or
not to postpone change events.
So:
Central.postponeAllChangeEvents()
Central.resumeAllChangeEvents()
Or maybe both:
p.postponeChangeEvents()
p.resumeChangeEvents()
I also foresee some unexpected behavior; suppose you have two properties bound bidirectionally. You set 1 on
the first and 2 on the second, in the end both properties will be set to 2. Now you postpone change events
and do the same, the end value depends on the order in which the components are resumed; if first component
"2" is resumed its change event is fired before "1" so in the end the properties will be
set to 1. If there were a central toggle and postponed events were registered to that central toggle, than
resuming events would "play back" the events in the same order they happened.
Just some considerations.
Tom
On 2013-12-16 0:39, Scott Palmer wrote:
Good stuff! This is the sort of thing that might make a good contribution
to extend the standard Bindings class.
Scott
On Sun, Dec 15, 2013 at 5:49 PM, Tomas Mikula <tomas.mik...@gmail.com>wrote:
On Sun, Dec 15, 2013 at 6:39 PM, Scott Palmer <swpal...@gmail.com> wrote:
Interesting idea.
There is a case I have been curious about and wonder what the best
practices
are for it. Suppose you have a case when you are changing multiple
different properties that will be used in a single calculation. You
want to
deal with a single change to all of them in one go. E.g. imagine you
have
an "area" property that is bound to both "width" and "height". You want
to
write code like:
obj.setWidth(w);
obj.setHeight(h);
and have only ONE recalculation of the area property happen. Currently
the
way bindings work the area will be calculated twice. The intermediate
calculation is really not a value that you ever want to observe.
Hi Scott,
this is precisely the problem that I'm trying to address here. Now,
the question is whether you have control over the implementation of
obj.
If yes, then it is the same case as the AND gate "motivational
example" from InhiBeans page. You provide a method setSize(w, h) and
use block()/release() to implement it in a way that causes only one
change of the area property.
If you cannot change the implementation of obj, what you can do is to
bind an inhibeans.binding.DoubleBinding to the "area" value, call it
relaxedArea, and listen to that one for all your purposes.
Then you resize obj like this:
relaxedArea.block();
obj.setWidth();
obj.setHeight();
relaxedArea.release();
Only one change of relaxedArea is emitted.
Best,
Tomas
Are there helpers for this sort of situation? Are there guidelines in
the
JavaFX docs somewhere?
Regards,
Scott
On Sat, Dec 14, 2013 at 11:54 PM, Tomas Mikula <tomas.mik...@gmail.com>
wrote:
Hello,
I just published a small extension of javafx bindings and properties
that can help you reduce redundant recalculations.
They provide two additional methods:
public void block();
public void release();
Call p.block() when you suspect your actions will lead to multiple
invalidations of p, and call p.release() when you are done and want to
deliver a single invalidation notification to p's observers.
https://github.com/TomasMikula/InhiBeans
Regards,
Tomas
