How to trigger property invalidation?

[Pavel Safrata]

Hello Werner,

On 4.11.2012 19:43, Werner Lehmann wrote:
>
> On 02.11.2012 19:12, Martin Sladecek wrote:
> > Hi Werner,
> > maybe an ObjectProperty isn't really what you are looking for. If you
> > have single bean with an non-observable property (BTW, how do you know
> > it has changed?) and you want to convert it to an FX property, why not
> > using a property of the same type as MyBean.myProperty and set FX
> > property when myProperty changes?
>
> Basically I made an FX custom control which serves as editor for a 
> domain bean (nothing too fancy).
>
> To understand this better, assume the following example. Let the bean 
> represent an employee with first name, last name, address, etc 
> properties. The editor would look like a form with text fields for 
> this stuff. I figured it would be neat to have an observable 
> "employee" property on that editor control:
> - set an employee value to initialize the editor control,
> - get an employee to retrieve the currently edited employee state, and
> - add a property listener to implement a dirty flag or somesuch.
>
> Obviously the editor knows when the employee changes. But it cannot 
> simply invalidate the property when only the address changes (assuming 
> that address is another bean).
>
> I am working around this by creating a whole new employee instance 
> with just a tiny change over the original employee so that I can 
> assign this to the property, thus forcing invalidation. To make things 
> worse, in my case I am using a slider to represent a zoom level - and 
> that creates a lot of noise (every move of the slider triggers a copy 
> of the bean).

I understand your concern, I've come across a similar issue some time 
ago. Your approach looks technically nice but conceptually is not so 
nice because the property refers to an employee, and even if the 
employee moved to a different address, it's still the same employee. 
Admitting it doesn't look so neat, here is the approach we've chosen:

The control has an observable "employee" property
The Employee has observable properties "first name", "last name" etc.
The Employee also has an EmployeeChangedEvent and fires it on itself 
whenever some of its properties changes

So you can:
- set an employee value to initialize the editor control
- get an employee to retrieve the currently edited employee (and than 
read the state from it)
- observe on the particular employee properties to see the changes done 
by the control, and/or
- listen to the employee changed event to implement the general dirty flag

The concept is nicer there because you tell to the control "now, edit 
this employee" and when edited it doesn't tell you "now, I'm editing a 
different employee" but instead tells you "I'm editing still the same 
employee, but its address has changed" via the "address" property 
listener, and "some of its properties have changed" via the event.

Regards,
Pavel