Bugzilla – Full Text Bug Listing
| Summary: | [DataBinding] JFace data binding | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | John Arthorne <john.arthorne> | ||||
| Component: | UI | Assignee: | Boris Bokowski <bokowski> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P4 | CC: | abuehler, alexberns, bill, bpasero, bradleyjames, c.hauser, chris_42, cloudor, codex69, daved, dev, djo, eclipse, ed.burnette, elias, fct.java, francois, frydzewski, gunnar, hoatranduy, jin.phd, Konstantin.Scheglov, mail, markus.kell.r, mike.haller, mlists, mpcarl, noelgrandin, og, pombredanne, rangwei, rjlorimer, sletelie, stepper, s_potijk, tobias.roeser, villane, wayne, wmitsuda | ||||
| Version: | 3.3 | Keywords: | plan | ||||
| Target Milestone: | 3.3 RC1 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | 116920, 118429, 128142, 140644, 147515, 147530, 147563, 153630, 159768, 160000, 164653, 167450, 169637, 171616, 171906, 172193, 177256, 177463, 177770, 183052, 183890 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
John Arthorne
*** Bug 104570 has been marked as a duplicate of this bug. *** I have moved a subset of the internal.provisional "API" from org.eclipse.jface.internal.databinding.provisional to org.eclipse.jface.databinding. Old code should continue to work since I kept all interfaces and classes in org.eclipse.jface.internal.databinding.provisional, but made them extend/implement the new API classes/interfaces. The old types are marked as deprecated. For the observable.* packages, it does not make sense to keep two copies. Instead, I will attach refactoring scripts to this bug. Please shout if you think this is not a good idea. Created attachment 49235 [details]
refactoring script: moving observables to API packages
Changes released to HEAD >20060831.
good news I've just looked at the latest changes to the JFace databinding framework 1.0.100 in eclipse 3.3M2 and I noticed the BindingFactory had disappeared I thought this was strange, in my opinion the ability to create custom bindings was one of the strong points of this binding framework. At my current project we are evaluating the JFace databinding framework to bind custom user interface components to a set of remote back end objects. The observable representing a remote attribute or operation should set or get its value asynchronously to make sure it does not block the user interface. Our custom 'remote value' binding would consider this by listening to stale events emitted by an observable. Is the ability to create custom bindings gone for good ? - Or have i missed some other way to retain this behavior ? Is the default value binding going to be listening to stale events in the future ? (In reply to comment #5) > I've just looked at the latest changes to the JFace databinding framework > 1.0.100 in eclipse 3.3M2 and I noticed the BindingFactory had disappeared > > I thought this was strange, in my opinion the ability to create custom bindings > was one of the strong points of this binding framework. > > At my current project we are evaluating the JFace databinding framework to bind > custom user interface components to a set of remote back end objects. > > The observable representing a remote attribute or operation should set or get > its value asynchronously to make sure it does not block the user interface. > > Our custom 'remote value' binding would consider this by listening to stale > events emitted by an observable. > > Is the ability to create custom bindings gone for good ? - Or have i missed > some other way to retain this behavior ? Is the default value binding going to > be listening to stale events in the future ? The short answer: Please see Bug 147563 for the background discussion behind this. :-) The somewhat longer answer: We can't ship an uber-factory as API because that factory needs to aggregate at least SWT, JFace, JavaBeans, and (eventually) EMF dependencies and we don't want to force all of those dependencies on folks. Actually, since we would like data binding to work on Java Foundation, we're already broken because java.beans is not available on Foundation. The solution has two parts: 1) Make DataBindingContext accept pairs of compatible Observable types. ie (IObservableValue, IObservableValue), (IObservableList, IObservableList), and so on. This eliminates some of the run-time checks we had before and allows Eclipse to provide better content assist when writing code. 2) Instead of having a single uber factory, have a single specialized factory for each dependency. So we now have SWTObservables, BeanObservables, and so on. You can write your own RemoteObservables or whatever you want to call it in order to support your own custom observables on remote objects. If you want to, you are still free to create your own uber-factory for your own application. I know that at my current client, we will do that (we actually already have; we'll just update it when we move to the new API), so while there might be more configuration and less convention, you can still do what you need to do. The flip side of the convention over configuration debate is that when writing API, it is important to make sure that your conventions are exactly right because at Eclipse, we don't change APIs. If we find a good way to do it, we can always add the uber-factory back later, but if we decide we hate it, we can't take it back once we've made it API. Lastly, we haven't totally settled on the exact syntax the factories will use. If you'd like to participate in the discussion, please join us at Bug 147563. (In reply to comment #5) > I've just looked at the latest changes to the JFace databinding framework > 1.0.100 in eclipse 3.3M2 and I noticed the BindingFactory had disappeared > > I thought this was strange, in my opinion the ability to create custom bindings > was one of the strong points of this binding framework. With the new API, you can create your own Binding subclass, instantiate it and add the binding instance to your context if you want this binding to be included when the context collects validation errors. It seems I've been too fast in posting my concerns and overlooked the new .addBinding function in the DataBindingContext. I should have known to look better as I already thought it was strange for the ability to create custom bindings to go missing. Anyway, sorry to bother you and thanks for the great work ! The way I understand it, the update policy (ie. DataBindingContext.TIME_EARLY and DataBindingContext.TIME_LATE) currently is enforced by the IObservableValue. Eg. the SWTObservableFactory has a setter #setUpdateTime(int), that creates instances of IObservableValue according to the policy. Wouldn't it be preferable to move this behaviour to the actual binding? This way the implementations of IObservableValue can remain very simple, as one does not have to take the several different policies into account. (In reply to comment #9) > The way I understand it, the update policy (ie. DataBindingContext.TIME_EARLY > and DataBindingContext.TIME_LATE) currently is enforced by the > IObservableValue. Eg. the SWTObservableFactory has a setter > #setUpdateTime(int), that creates instances of IObservableValue according to > the policy. In the latest version of Databinding this is no longer the case as SWTObservableFactory is deprecated. For the replacement to this functionality see SWTObservables.getText(...). > Wouldn't it be preferable to move this behaviour to the actual binding? This > way the implementations of IObservableValue can remain very simple, as one does > not have to take the several different policies into account. It needs to be at the observable level as this tells the observable when to fire change events. In the case of Text this means the events need to be fired on Modify rather than FocusOut. (In reply to comment #10) My mistake, I confused the purpose of the TIME_* constants with that of the POLICY_* constants. The scenario I had in mind was the scenario where you have to push an "OK" button or sth similar, and looking at the code I mistakenly thought that it was the responsibilty of the IObservableValue to wait for that event to happen iso the Binding itself. I have since seen however that one can specify this behaviour in the BindSpec (through the #setModelUpdatePolicy(int) and #setTargetUpdatePolicy(int) methods), and that this behaviour is indeed part of the Binding. > (In reply to comment #9) > > The way I understand it, the update policy (ie. DataBindingContext.TIME_EARLY > > and DataBindingContext.TIME_LATE) currently is enforced by the > > IObservableValue. Eg. the SWTObservableFactory has a setter > > #setUpdateTime(int), that creates instances of IObservableValue according to > > the policy. > > In the latest version of Databinding this is no longer the case as > SWTObservableFactory is deprecated. For the replacement to this functionality > see SWTObservables.getText(...). > > > Wouldn't it be preferable to move this behaviour to the actual binding? This > > way the implementations of IObservableValue can remain very simple, as one does > > not have to take the several different policies into account. > > It needs to be at the observable level as this tells the observable when to > fire change events. In the case of Text this means the events need to be fired > on Modify rather than FocusOut. > Is it possible that the behaviour described above (about waiting for an OK button) is not yet implemented in the current code ? A couple of bugs off the top of my head that I'd like to see resolved before the official release. bug 140644 - [DataBinding] Binding to ValidationError of DataBindingContext is broken bug 147563 - [DataBinding] Need a standard factory for data binding contexts bug 128142 - [DataBinding] IDomainValidator needs to provide partial validation / be merged with IValidator The javadoc for IDomainValidator states "FIXME: This is wrong.". agree. (In reply to comment #12) > Is it possible that the behaviour described above (about waiting for an OK > button) is not yet implemented in the current code ? You are right, it is not implemented yet. I have filed bug 159768 for this. Here is another issue I would like to investigate (ideally solve) before finalizing the API: bug 116920 - [DataBinding] need to handle model change events which don't happen in the UI thread Here is a question for cc list members: Does anyone know about the problems (or solutions) when tring to use the Observer pattern in a concurrent environment, with notifications that are incremental? Responses on bug 116920 please. Observer: I*ChangeListener Subject: IObservable concurrent environment: model change events on one thread, widgets can only be accessed on another thread incremental notifications: This is not an issue for IObservableValue, but is important for IObservableList/IObservableSet Since we're planning... bug 160000 - [DataBinding] Convert scenarios to official APIs Just a heads up - as per discussion on bug 153630, the data binding plug-ins will be renamed as follows: org.eclipse.core.databinding (core data binding framework, requires only org.eclipse.equinox.common, contains general-purpose observables, converters, validators, bindings) org.eclipse.core.databinding.beans (beans observables) org.eclipse.jface.databinding (SWT and JFace observables) This will happen early in the 3.3 M4 development cycle. The plug-ins have been renamed, and the changes for bug 116920 (concurrency) are in the new plug-ins in HEAD. I have given up on keeping the old API functional (sorry for that - it was just too much work), so basically this will be a big bang kind of change for those of you who already used the old API. We also need to add dependencies on: * bug 118429 * bug 147530 * bug 164653 Adding bug 147515 - [DataBinding] separate run-time type information from IObservable Marking as fixed. Marking as verified. This is truly a milestone for Eclipse Data Binding. I'd like to publicly thank everyone who made this possible, especially Boris Bokowski, Brad Reynolds and everyone who has submitted bug reports, feedback, and patches! Dave Orme I shouldn't have forgotten to mention Gili Mendel and the whole former VE team for helping get this effort off the ground to begin with. Without them, we couldn't be where we are today. Thanks! congrats guys! |