[announce] InhiBeans: mitigate redundant recalculations

[Tom Eugelink]

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.mikula at gmail.com>wrote:
>
>> On Sun, Dec 15, 2013 at 6:39 PM, Scott Palmer <swpalmer at 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.mikula at 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
>>>