Community
Participate
Working Groups
As a workaround for bug #356291 , it would be nice to provide a way to use databinding with FeatureMaps. I am thinking of a method EMFEditObservables.observeFeatureMapEntry(editDomain, myEObject.getFeatureMap(), eStructuralFeature)
Given a FeatureMap is just a list of feature map entries, what's special for this?
I have a text widget that I want to bind to the value for an Entry in a FeatureMap, whose key would be a given Feature. I need to have an IObservableValue from the containment group + the key feature. The entry may not exist before, the databinding could have to create it. Since a FeatureMap is not an EObject, there is not eSet on this, and then the SetCommand, used in the EMFEditObserveValue, does not apply.
What you're describing though is (sounds like) the other bug. A feature map is just a list, so what is special about this type of list as opposed to any other multi-valued EMF feature?
The thing here is that I don't want to observe the whole list or the whole FeatureMap, but just one value for a specific given feature/key. It is a bit like if I would like to observe a single list item, for a given position.
This sounds like a duplicate of https://bugs.eclipse.org/bugs/show_bug.cgi?id=356291, i.e., if that one is done, there's nothing left to do for this is there?
I don't see this request as a bug. I am simply making a feature request to have some additional methods in EMF DataBinding framework to handle FeatureMap more easily. This would be an alternative to bug #356291 and some other kind of hacks ;)
I don't understand how this EMFEditObservables.observeFeatureMapEntry(editDomain, myEObject.getFeatureMap(), eStructuralFeature) is different from this EMFEditObservables.observeList(editDomain, myEObject, eStructuralFeature) I.e., what special capability are you requesting that's not already supported? Of course you might argue that you're asking to support the case where eStructuralFeature isn't the feature map EAttribute itself, but, as I suggested, that's what the other bugzilla is about. So I'm concluding there's nothing substantial being requested here. I might be missing something, but you'll need to make that clear.
EMFEditObservables.observeList(editDomain, myEObject, eStructuralFeature) returns a IObservableLIST, which works well when binding it to multivaluated widgets. It does not observe the _whole list_ item, but it observes the whole list. EMFEditObservables.observeFeatureMapEntry(editDomain, myEObject.getFeatureMap(), eStructuralFeature) would return an IObservableVALUE which would observe the _value_ in the featureMap for the given feature. With this second solution, one would not have to deal with FeatureMapUtil, Entry, and so on. All that stuff would be hiddon inside the Observable.
Note that you didn't show me the return type of the new method you're proposing, and there was no way to infer it... From what you describe, I continue to conclude that what you're asking for is the same what EMFObservables.observeValue/observeList already provide, *if* those things supported open content features rather than just features actually owned by eObject.eClass(). Am I still missing something? Note that a feature map corresponding to a wildcard can be single- or multi-valued which determines whether the open content features are single or multi-valued in that context.
(In reply to comment #9) > Note that you didn't show me the return type of the new method you're > proposing, and there was no way to infer it... Sorry about this. I am so much into my idea that I forget to give details that are not obvious. > From what you describe, I continue to conclude that what you're asking for is > the same what EMFObservables.observeValue/observeList already provide, *if* > those things supported open content features rather than just features actually > owned by eObject.eClass(). Am I still missing something? Yes, that's the use case I have. Ideally, the solution would be to provide open content directly on the EObject, as already discussed on the forum. But since it is not possible, I currently rely on FeatureMap for open content. > Note that a feature map corresponding to a wildcard can be single- or > multi-valued which determines whether the open content features are single or > multi-valued in that context. I am not sure to understand this point. Do you mean that the value of a FeatureMap.Entry can be a single value or a list, leading to different methods when using databinding?
If i get that right we already support this because in 2.7 we added the possibility to observe an element inside a list (IEMFListProperty#value(ElementAccessImpl)). See http://tomsondev.bestsolution.at/2011/05/06/interesting-new-feature-in-emf-databinding/
Mickael, So, the point is that eGet/eSet and so on already work for open content features, so one should expect the same things to work with commands (as in the other bugzilla). One would also expect all the existing observables to work, because they either use eGet/eSet (which already works) or the commands (which should work but don't). That's why I say, all you really need is for the commands to work and all will be good. I don't think feature maps need anything special. Either you use them directly, in which case you're dealing with a list of feature map entries, or you ignore them completely and rely on open content working properly in all cases. So there really is nothing to do for this bugzilla, right? Tom, I'm not sure that really helps him so much because he'd still be dealing with a FeatureMap.Entry value, which he's trying to hide...
Ed, I now have the mind clear enough to confirm that you are right (once again ;). Fixing bug #356291 would invalidate this bug. Thanks for your patience, and sorry for being confused. As you already said, EMF is not very easy to fully understand, and I got a bit lost in all this eOpenSet stuff. *** This bug has been marked as a duplicate of bug 356291 ***
