Eclipse Community Forums: EMF » [EMF/Databinding] xsd:choice attribute

Help

Home

Home » Modeling » EMF » [EMF/Databinding] xsd:choice attribute

Show: Today's Messages :: Show Polls :: Message Navigator

[EMF/Databinding] xsd:choice attribute [message #830360]

Tue, 27 March 2012 14:34

Christophe Bouhier

Messages: 937
Registered: July 2009

Senior Member

Hi there,

I have this requirement, that I need to hold different types into a collection and maintain the order.

As I always start from xsd, I modelled it like this:

...
<xs:sequence>
                <xs:choice maxOccurs="1">
		       <xs:element name="ReferenceRelationship" ecore:reference="library:ReferenceRelationship" type="xs:anyURI">
		       </xs:element>
		       <xs:element name="ServiceFlow" ecore:reference="ServiceFlow" type="xs:anyURI">
		       </xs:element>
		</xs:choice>
</xs:sequence>
...

I was somewhat surprised to see, I get two features, for the EClass from this complextype (omitted in the snippet), when generating the model code.

So now I wonder, if there is alternative to achieve the same thing, and whereby only one EStructuralFeature is created for the choice?

The reason, is that with databinding two features is problematic in the case of a ObservableValueEditingSupport, which binds early on a feature, and can't really retarget the binding to another feature when editing a list holding both possible choices.

Thank you,
Christophe Bouhier

Report message to a moderator

Re: [EMF/Databinding] xsd:choice attribute [message #830522 is a reply to message #830360]

Tue, 27 March 2012 18:44

Ed Merks

Messages: 33141
Registered: July 2009

Senior Member

Christophe,

Comments below.

On 27/03/2012 10:34 AM, Christophe Bouhier wrote:
> Hi there,
> I have this requirement, that I need to hold different types into a
> collection and maintain the order.
> As I always start from xsd, I modelled it like this:
>
> ..
> <xs:sequence>
> <xs:choice maxOccurs="1">
The default for maxOccurs is one anyway. You said you needed a
collection though...
> <xs:element name="ReferenceRelationship"
> ecore:reference="library:ReferenceRelationship" type="xs:anyURI">
> </xs:element>
> <xs:element name="ServiceFlow" ecore:reference="ServiceFlow"
> type="xs:anyURI">
> </xs:element>
> </xs:choice>
> </xs:sequence>
> ..
>
>
> I was somewhat surprised to see, I get two features, for the EClass
> from this complextype (omitted in the snippet), when generating the
> model code.
Well, there's no such thing as a choice in Ecore itself.
> So now I wonder, if there is alternative to achieve the same thing,
> and whereby only one EStructuralFeature is created for the choice?
Not really. You could add a named constraint that's implements so it's
only valid to populate one of the two features.
> The reason, is that with databinding two features is problematic in
> the case of a ObservableValueEditingSupport, which binds early on a
> feature, and can't really retarget the binding to another feature when
> editing a list holding both possible choices.
I'm not sure what to suggest for that...
>
> Thank you, Christophe Bouhier
>
>

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator