Community
Participate
Working Groups
When editing objects that are managed by a persistence tier like Hibernate, one needs to tell Hibernate when to save changes to objects. The usual way to do this is to add a binding event listener that tells the persistence layer to write changes immediately after successful completion of a BindingEvent.EVENT_COPY_TO_MODEL. This works well for small object graphs because you can just tell Hibernate to save the whole object graph, and let Hibernate work out what actually needs to be saved. This doesn't work well for large object graphs because the amount of time Hibernate needs to compute what needs saved and to perform the actual save can rise into a very noticable amount of time--seconds--if you ask Hibernate to save the whole object graph at once. What is needed is a way for the BindingEventListener to determine the actual object that just changed, and to ask Hibernate to save just the relevant portion of the object graph. We currently cannot do this, because BindingEvent.target and BindingEvent.model are just IObservables and IObservableValue.getValue() returns the value of the property that changed, not the object itself. Therefore, what is needed is API on IObservable to return the object that it is wrapping--say, IObservable.getWrappedObject() or IObservable.getBackingObject(). We have implemented this in the older version of data binding that we are still using until after our big release. The only tricky thing we ran into was how to implement this for nested observables. In that case, the solution was to return currentOuterValue (which could be null) as the wrapped object. Marking major since this is pretty fundamental and probably needs to make it in before M5.
+1 for this but as an optional mix-in interface which is implemented by at least the Java bean observables (returning the bean), the SWT observables (returning the control), but not by e.g. WritableList and the like.
(In reply to comment #1) > +1 for this but as an optional mix-in interface which is implemented by at > least the Java bean observables (returning the bean), the SWT observables > (returning the control), but not by e.g. WritableList and the like. Why not Writable*? WritableList: return this; WritableSet: return this; WritableValue: return getValue(); Am I missing something?
Not all observables wrap something else.
(In reply to comment #3) > Not all observables wrap something else. > Maybe the API should be called public Object getObservedObject(); ? That way, Writable* objects could feel free to `return this` and Observables that are abstractions for something else could return the thing they are abstracting.
Another observable that would have an issue with the generic approach is ComputedValue. I agree with Boris that it might be best to keep this specific to beans. You could then return the observed object and also the property being observed for optimzation/debugging purposes.
(In reply to comment #5) > Another observable that would have an issue with the generic approach is > ComputedValue. Wait! (Please re-read comment #4) If the API is: getObservedValue() then ComputedValue can return this; Then there are no issues. :)
What I meant was that it wouldn't make sense for that type of observable. It could be done, yes, but I'm not seeing the point for it in all observables. It seems like returning 'this' would be just to pacify the API rather than returning an appropriate value, at least for ComputedValue.
Hmmm; not sure why this is "pacifying the API" Logically, an Observable will have something that is being observed; after all, that's the whole point of being Observable. Within this context, there are two choices: either the Observable is wrapping something, or the Observable itself supplies the abstraction that is being observed. So, it makes perfect sense to me to have API on all Observables to: public Object getObservedValue(); In the former case, the wrapped value will be returned; in the latter, 'this' will be returned. Am I missing something?
But what is the point of returning 'this'? That's what I'm not getting and my comment that it was just pacifying the API. My viewpoint is that it doesn't make sense for the abstractions to have the API. Plus what if we wanted ComputedValue to one day return the observables that it is wrapping? I would think that would be more correct than returning 'this'. I'm just having an issue seeing why the API needs to be on all observables. Plus I would think that it would be simpler for there to be API on each type of observables (beans, widgets, etc.) that can be tailored to that type of object. Then for beans you could return the property as well. And for the abstractions that don't necessarily observe a specific object we wouldn't provide the API. So actually I'm missing something. :)
Dave, is it OK to close this? We introduced IBeanObservable in 3.3M5 in bug 171616.
public interface IObserving { /** * Returns the observed object, or <code>null</code> if this observing * object does not currently observe an object. * * @return the observed object, or <code>null</code> */ public Object getObserved(); }
Released (as part of the fix for bug 175840) >20070312.
in I20070322-1800 PW
