Point made.
Tom
On 2013-12-16 12:17, Tomas Mikula wrote:
On Mon, Dec 16, 2013 at 7:56 AM, Tom Eugelink <t...@tbee.org> wrote:
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
Hi Tom,
global postpone/resume defeats the original goal of avoiding multiple
change events. Consider
Central.postponeAllChangeEvents();
obj.setWidth(w);
obj.setHeight(h);
Central.resumeAllChangeEvents();
Now, if the changes are replayed, the width change causes one change
of the area property, and height change another one.
You are right about the problem with bidirectionally bound properties.
I don't know all the useful use cases for bidirectional bindings (I
never used them personally), but it might as well be the case that the
scenario you described never happens. InhiBeans are intended for
internal implementation of a component. Only the component itself
would call block()/release(). These methods aren't even available to
the client of the component without downcasting the properties.
Methods of the component can call block() internally, but should
release() before returning.
Regards,
Tomas
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
