How to trigger property invalidation? (original) (raw)
Pavel Safrata pavel.safrata at oracle.com
Mon Nov 5 00:46:31 PST 2012
- Previous message: How to trigger property invalidation?
- Next message: How to trigger property invalidation?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: How to trigger property invalidation?
- Next message: How to trigger property invalidation?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]