Community
Participate
Working Groups
I want to use DataBinding APIs to implement a form-style editor that acts on a viewer multiple-selection. I've just submitted a possible solution (in bug 124683) for observing the multiple-selection. The next stage in the pipeline is to translate an IObservableList of masters into an IObservableList of details. (I will submit a new bug for this shortly.) Finally, a DuplexingObservableValue should translate an IObservableList of separate detail IObservableValues into a single IObservableValue that can be bound to an SWTObservableValue target. The behavior of DuplexingObservableValue depends on whether all items in the IObservableList are equal by IObservableValue.getValue().equals(). If so, DOV.getValue() should delegate to the first item in the list. (Since all items are equivalent, the first item is as good as any.) If the items are not equal, DOV.getValue() should return a stand-in value, which must be provided in advance. The stand-in value for a value of type String might be a message, such as "<multiple values>". In any case, DOV.setValue() should iterate over the entire list of items and set them all to the new value. If the value of any IObservableValue changes, DOV must re-check for equality and report the new combined value (if necessary). Note: It would be the responsibility of the client code to ensure that appropriate validation and conversion is provided when the Binding is created. For the simple case where all detail values have the same validation rules, DuplexingObservableValue would be a drop-in replacement for an existing IObservableValue. If the details require individually distinct validation, the AndValidator submitted to bug 147489 might be useful. Distinct conversion would be difficult (perhaps impossible), but is unlikely to be needed in practice. It doesn't make much sense conceptually to edit multiple values with distinct types using a single UI element.
See bug 175737 for the second stage of the pipeline described above. (IObservableList source, piecewise translated into an IObservableList of details.)
In case this is not obvious from my description, implementing this pipeline would be a big win for DataBindings. It would enable any master-detail binding to edit a multiple-selection merely by providing an appropriate stand-in value. Almost everything else can be encapsulated in a static factory method. For primitive types and their wrappers, stand-in values can be provided automatically. A multiple-selection binding would take exactly the same amount of code as a single-selection binding. Sexy UI features for free! The reason I must say "almost everything" instead of "everything" is because of validation. Model-to-target validators and converters must accept the stand-in value so that it can be set on the target. Partial validation should give sufficient leeway for a user to move from the stand-in state to a real value. AFAIK, there are stand-in values that will work for all of the types understood by the built-in classes. For example, null will work with Combo, CCombo, and List selections; any String will work for text properties; null will work for models with various Number types. Most client code should have zero trouble, and clients that use lots of custom types will have easy incremental work to get multiple-selection support working. I think this would take DataBindings to 11, so to speak. :-)
Welcome to observable wonderland! :-) What you propose makes sense to me. Given the time constraints for API changes, I don't think we can add this to the API for the 3.3 release, but we could put classes like this in an internal package for now.
Would be nice to have something like this for 3.4.
Boris, I'll try my hand at this one. (In reply to comment #0) > The next stage in the pipeline > is to translate an IObservableList of masters into an IObservableList of > details. This stage can now be accomplished using properties: IObservableList multiSelect = ViewerProperties.multipleSelection() .observe(tableViewer); IObservableList selectionNames = BeanProperties.value(Person.class, "name") .observeDetail(multiSelect);
Created attachment 123708 [details] Patch with tests, snippet The snippet makes a good case for this feature
Created attachment 123709 [details] mylyn/context/zip
Created attachment 123767 [details] Updated snippet to include more movies, to demonstrate duplexing of multiple selection
Created attachment 123768 [details] mylyn/context/zip
Released to HEAD > 20090126
Those CC'd on this bug may want to participate in bug 262407 as well
Verified in I20090129-0100 by running Snippet028DuplexingObservableValue
