Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Is this a bug? Databindings don't seem to check isSet
Is this a bug? Databindings don't seem to check isSet [message #1049972] Fri, 26 April 2013 14:25 Go to next message
Ben Cox is currently offline Ben CoxFriend
Messages: 17
Registered: June 2012
Junior Member
Hi all,

I'm currently binding a combo box into my EMF model. The combo box is being bound to an attribute that was generated from an XSD with the following structure:

<xsd:attribute name="myAttr">
	<xsd:simpleType>
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="A"/> 
			<xsd:enumeration value="B"/> 
			<xsd:enumeration value="C"/>
		</xsd:restriction>
	</xsd:simpleType>
</xsd:attribute>


You'll notice that the attribute, by virtue of no use="required" parameter, is optional. In order to deal with this and allow the user to 'unset' the attribute once set, I've added an additional blank element to the ComboViewer's input.

I've then bound the ComboViewer's selection to the model using the following:

myAttrDetailValue = EMFEditObservables.observeDetailValue(myObjectValue.getRealm(), editingDomain, myObjectValue, MyObjectPackage.Literals.MY_OBJECT_TYPE__MYATTR);
ctx.bindValue(
	ViewerProperties.singleSelection().observe(myAttrComboViewer),
	myAttrDetailValue,
	new EMFUpdateValueStrategy().setConverter(...),
	new EMFUpdateValueStrategy().setConverter(...)
);


As you can see, myAttrDetailValue is a detail observable of myObjectValue, which is in turn bound into the ComboViewer's selection. The Converters sort out the conversion from the 'empty' combo element to null and vice versa.



OK, that's the setup. Now here's the problem. I set the value of myObjectValue to something where myAttr is unset, resulting in the detail observable being recalculated. However, instead of first checking whether isSetMyAttr() returns true (and returning null because it's not set) it instead goes straight to getMyAttr() which returns "A", the first value in the enumeration. This causes the combo to immediately have the wrong value.

Am I doing something wrong, or is this a bug?




For reference, here's a snapshot of the relevant section of the stack trace:

Thread [main] (Suspended (entry into method getMyAttr in MyObjectTypeImpl))	
	MyObjectTypeImpl.getMyAttr() line: 1641	
	MyObjectTypeImpl.eGet(int, boolean, boolean) line: 3454	
	MyObjectTypeImpl(BasicEObjectImpl).eGet(EStructuralFeature, boolean, boolean) line: 1011	
	MyObjectTypeImpl(BasicEObjectImpl).eGet(EStructuralFeature, boolean) line: 1003	
	MyObjectTypeImpl(BasicEObjectImpl).eGet(EStructuralFeature) line: 998	
	EditingDomainEObjectObservableValue(EObjectObservableValue).doGetValue() line: 129	
	EditingDomainEObjectObservableValue(AbstractObservableValue).getValue() line: 76	
	DetailObservableValue.doGetValue() line: 146	
	DetailObservableValue$2.handleValueChange(ValueChangeEvent) line: 93	
	ValueChangeEvent.dispatch(IObservablesListener) line: 62	
	DetailObservableValue(ChangeManager).fireEvent(ObservableEvent) line: 119	
	DetailObservableValue(AbstractObservableValue).fireValueChange(ValueDiff) line: 71	
	DetailObservableValue.access$1(DetailObservableValue, ValueDiff) line: 1	
	...
Re: Is this a bug? Databindings don't seem to check isSet [message #1050471 is a reply to message #1049972] Sat, 27 April 2013 07:56 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33107
Registered: July 2009
Senior Member
Ben,

This is just a perennial problem. An even simpler example of this
"binding problem" is binding a String attribute to a text widget. How do
you tell the difference between a null value and the empty string value
in the widget? You don't. You'd need some extra little check box or
something else...

As for this issue of enums and unsettable you should search the
newsgroup for all the previous times I've explained that enums are
treated by EMF like primitive types, i.e., they cannot return null from
eGet or from the generated getter. In the properties view there is an
unset button that helps give control of the difference between unset
verse set to the default value (even for the string case above). But
that's not available for data binding. For the case of generating the
values for a drop down combo box, you might argue it should
automatically include one addition choice representing "<unset>". But
would should it do for the simple case (String attribute bound to Text
widget) above?


On 26/04/2013 4:25 PM, Ben Cox wrote:
> Hi all,
>
> I'm currently binding a combo box into my EMF model. The combo box is
> being bound to an attribute that was generated from an XSD with the
> following structure:
>
> <xsd:attribute name="myAttr">
> <xsd:simpleType>
> <xsd:restriction base="xsd:string">
> <xsd:enumeration value="A"/> <xsd:enumeration value="B"/>
> <xsd:enumeration value="C"/>
> </xsd:restriction>
> </xsd:simpleType>
> </xsd:attribute>
>
> You'll notice that the attribute, by virtue of no use="required"
> parameter, is optional. In order to deal with this and allow the user
> to 'unset' the attribute once set, I've added an additional blank
> element to the ComboViewer's input.
>
> I've then bound the ComboViewer's selection to the model using the
> following:
>
> myAttrDetailValue =
> EMFEditObservables.observeDetailValue(myObjectValue.getRealm(),
> editingDomain, myObjectValue,
> MyObjectPackage.Literals.MY_OBJECT_TYPE__MYATTR);
> ctx.bindValue(
> ViewerProperties.singleSelection().observe(myAttrComboViewer),
> myAttrDetailValue,
> new EMFUpdateValueStrategy().setConverter(...),
> new EMFUpdateValueStrategy().setConverter(...)
> );
>
> As you can see, myAttrDetailValue is a detail observable of
> myObjectValue, which is in turn bound into the ComboViewer's
> selection. The Converters sort out the conversion from the 'empty'
> combo element to null and vice versa.
>
>
>
> OK, that's the setup. Now here's the problem. I set the value of
> myObjectValue to something where myAttr is unset, resulting in the
> detail observable being recalculated. However, instead of first
> checking whether isSetMyAttr() returns true (and returning null
> because it's not set) it instead goes straight to getMyAttr() which
> returns "A", the first value in the enumeration. This causes the combo
> to immediately have the wrong value.
>
> Am I doing something wrong, or is this a bug?
>
>
>
>
> For reference, here's a snapshot of the relevant section of the stack
> trace:
>
> Thread [main] (Suspended (entry into method getMyAttr in
> MyObjectTypeImpl))
> MyObjectTypeImpl.getMyAttr() line: 1641
> MyObjectTypeImpl.eGet(int, boolean, boolean) line: 3454
> MyObjectTypeImpl(BasicEObjectImpl).eGet(EStructuralFeature,
> boolean, boolean) line: 1011
> MyObjectTypeImpl(BasicEObjectImpl).eGet(EStructuralFeature,
> boolean) line: 1003
> MyObjectTypeImpl(BasicEObjectImpl).eGet(EStructuralFeature) line: 998
> EditingDomainEObjectObservableValue(EObjectObservableValue).doGetValue()
> line: 129
> EditingDomainEObjectObservableValue(AbstractObservableValue).getValue()
> line: 76
> DetailObservableValue.doGetValue() line: 146
> DetailObservableValue$2.handleValueChange(ValueChangeEvent) line: 93
> ValueChangeEvent.dispatch(IObservablesListener) line: 62
> DetailObservableValue(ChangeManager).fireEvent(ObservableEvent)
> line: 119
> DetailObservableValue(AbstractObservableValue).fireValueChange(ValueDiff)
> line: 71
> DetailObservableValue.access$1(DetailObservableValue, ValueDiff)
> line: 1
> ...


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Is this a bug? Databindings don't seem to check isSet [message #1050572 is a reply to message #1050471] Sat, 27 April 2013 11:38 Go to previous message
Ben Cox is currently offline Ben CoxFriend
Messages: 17
Registered: June 2012
Junior Member
Hi Ed,

Thanks for your reply. Sorry I didn't find any of your previous responses - I obviously wasn't searching on the correct terms (didn't realise it was specifically an issue that affected enums, so didn't search for them!).

Different people will want different things to happen for their various differing models, UIs and use cases - as you say, some people might want an empty Text to translate into a null and unset the value, whereas others might want the attribute to remain set as the empty string, so there's not a one-size-fits-all solution - I can understand that.

For others' reference, I've just coded up a solution for my particular problem by adding a bit of logic into the model-to-target Converter that first asks the parent myObjectValue's value whether the attribute is set, and if not returns the 'unset' value for the ComboViewer to use.
Previous Topic:[Teneo] DB Schema on Teneo Audit
Next Topic:exporting cdo server feature product
Goto Forum:
  


Current Time: Tue Mar 19 09:53:57 GMT 2024

Powered by FUDForum. Page generated in 0.03185 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top