On Mon, Dec 16, 2013 at 12:17 PM, Tomas Mikula <tomas.mik...@gmail.com> 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.
I should have added that I assume that you never use bidirectional binding within one component, but only to bind properties of two components. > 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 >>>>> >>>>> >> >>
