Eclipse Community Forums: Sapphire » XSD implementation advice: <xs:choice>

Help

Home

Home » Archived » Sapphire » XSD implementation advice: <xs:choice>

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

XSD implementation advice: <xs:choice> [message #760508]

Fri, 02 December 2011 16:08

Roded Bahat

Messages: 152
Registered: August 2011

Senior Member

Hi,
I'm in the process of creating Sapphire interfaces (mostly based on an XSD) for the purpose of editing XML via an editor.
Before, jumping ahead, I figured I might ask what is the proposed way of implementing
the following scenario in Sapphire:
My XSD has a type (named "Value") which is composed of a <xs:choice> group of several elements.
Another type (named "NamedValue") extends "Value" and adds a name property to it.
When the user will be adding a NamedValue element in the editor, his/her options should be the different kinds of element in the Value's choice group..
Would appreciate any pointers.
Thanks,
Roded

Report message to a moderator

Re: XSD implementation advice: <xs:choice> [message #760623 is a reply to message #760508]

Sat, 03 December 2011 16:32

Roded Bahat

Messages: 152
Registered: August 2011

Senior Member

As the Sample's IOccupation, this worked for me:

// *** Value ***
@Label(standard = "Value")
@Type (
		base = IValue.class, 
        possible = { 
            IXSDValueType1.class,
            IXSDValueType2.class
        }
    )
@XmlElementBinding ( 
        mappings = {
        @XmlElementBinding.Mapping( element = "valuetype1tag", type = IXSDValueType1.class,),
        @XmlElementBinding.Mapping( element = "valuetype2tag", type = IXSDValueType2.class)
        }
    )
	
ElementProperty PROP_VALUE = new ElementProperty(TYPE, "Value");
ModelElementHandle<IValue> getValue();

[Updated on: Sat, 03 December 2011 16:32]

Report message to a moderator

Re: XSD implementation advice: <xs:choice> [message #760635 is a reply to message #760623]

Sat, 03 December 2011 18:19

Konstantin Komissarchik

Messages: 1077
Registered: July 2009

Senior Member

Yes, a heterogeneous element property like contact database sample's occupation property is a good way to go in situations like yours. Especially when there is extensive content beneath those child elements (as opposed to a single value). If each of those child elements represent a single value, then there are other modeling patterns that could work as well. If that is your case, let me know and I will elaborate.

- Konstantin

Report message to a moderator

Re: XSD implementation advice: <xs:choice> [message #760638 is a reply to message #760635]

Sat, 03 December 2011 18:25

Roded Bahat

Messages: 152
Registered: August 2011

Senior Member

Hi Konstantin,
As it happens, each of the children interfaces has only one value.
Currently, my IValue interface is empty and every child interface implements its own value.
I tried moving all of the childrens' values to the IValue interface and setting the labels and such in the extending interfaces (IXSDValueType*) but that made it difficult for me to check the type of the property in an <if> (in order to show different display elements for every IXSDValueType).
Please do elaborate if you have some inputs on the matter.
Thanks

Report message to a moderator

Re: XSD implementation advice: <xs:choice> [message #760645 is a reply to message #760638]

Sat, 03 December 2011 19:55

Konstantin Komissarchik

Messages: 1077
Registered: July 2009

Senior Member

Here are some other modeling patterns that may be useful for your scenario:

1. Use a single IValue interface (no extending types). Create a specifically-typed value property for each data type allowed by the schema. Use standard XML binding syntax on those value properties. Then, either...

A. Show all properties concurrently in the UI. Use validation (via a custom ValidationService implementation) to inform the user that only one can be set.

B. Create an enum property to represent the datatype. Write a custom XML binding for that property to hinges on which child element is present. For instance, change the value of the datatype property would delete the old child element and create a blank one for the new datatype. Use @Enablement on properties holding the actual data referring the datatype property. Then use <if> constructs in sdef (again referring to the datatype property) to only show the relevant value field.

2. Sapphire supports value properties holding arbitrary data. So you could define a new class (let's call it Variant) that can hold an int, a float or whatever your choices are. Just make sure that the Variant class in immutable (Sapphire model requirement) and that you can ask it what type it is holding. Then write an implementation of SerializationService that knows how to convert Variant to/from String. In your IValue, you will have a single value property of type Variant. At this point, you still need to specify xml binding. This will need to be a custom binding as you will have to be able to figure out to which child element to write to based on Variant's datatype.

Hope this helps.

- Konstantin

Report message to a moderator

Re: XSD implementation advice: <xs:choice> [message #760646 is a reply to message #760645]

Sat, 03 December 2011 19:58

Konstantin Komissarchik

Messages: 1077
Registered: July 2009

Senior Member

Note that in option #2 above, user will not have direct control over datatype (the child element). They will type the value into the text field and you will infer the type, which will subsequently infer the child element. Depending on your requirements this maybe a bad thing or a good thing.

- Konstantin

Report message to a moderator

Re: XSD implementation advice: <xs:choice> [message #760659 is a reply to message #760646]

Sat, 03 December 2011 23:18

Roded Bahat

Messages: 152
Registered: August 2011

Senior Member

Thanks, it does help.
It's a bit of an effort with the samples as the main reference.
I've had 1.B. implemented at some point, but then the issue was to allow the user to add each of the different types via the Content Outline Node Factory. Is this possible instead of having the user choose the type via a combobox? And also, though probably trivial, how do I set the enum property as not xml bound at all?
Regarding 2. Do you mean something along the lines of Circle.java in the gallery sample?

Thanks again,
Roded

Report message to a moderator

Re: XSD implementation advice: <xs:choice> [message #760668 is a reply to message #760659]

Sun, 04 December 2011 04:09

Konstantin Komissarchik

Messages: 1077
Registered: July 2009

Senior Member

Quote:

I've had 1.B. implemented at some point, but then the issue was to allow the user to add each of the different types via the Content Outline Node Factory. Is this possible instead of having the user choose the type via a combobox?

If you want this behavior, you will have to use the heterogeneous element property solution that you have already implemented.

Quote:

And also, though probably trivial, how do I set the enum property as not xml bound at all?

You would need to implement a custom XML binding. See @CustomXmlValueBinding. In this custom binding, you would determine the value of the enum based on which child element was present. When a new enum value is written, you would remove one child element and add a different one.

Quote: