Two tips for the Eclipse Modeling Framework (EMF) 2.2.1:
- Accessing model’s meta model – accessing EClass/attribute by name – so that you can set an attribute when you only know its name and haven’t its EAttribute
- How to force EMF to serialize an object as an XML element instead of an XML attribute
Excuse my rather liberal and slightly confusing use of the terms model, model instance and meta model.
Tip 1: Accessing model’s meta model – accessing EClass/attribute by name
Normally you cannot do any operation on a dynamic EMF model instance – such as instantiating an EObject or settings its property via eSet – without the corresponding meta model objects such as EClass and EAttribute. But there is a solution – you can build an ExtendedMetaData instance and use its methods to find the meta model objects based on search criteria such as element name and namespace.
Create ExtendedMetaData from a model
One way to build a meta data instance is to instantiate BasicExtendedMetaData based on a Registry, containing all registered packages. This is usually available either via ResourceSet.getPackageRegistry() or globally, via EPackage.Registry.INSTANCE.
import org.eclipse.emf.ecore.util.*; ... ExtendedMetaData modelMetaData = new BasicExtendedMetaData(myResourceSet.getPackageRegistry());
Get EClass for a namespace and name
Provided that your model contains an element with the name Book and namespace http://example.com/book:
EClass bookEClass = (EClass) modelMetaData.getType("http://example.com/book", "Book");
Get EClass’ attribute by name
Beware: Some properties (such as those described by named complex types) are not represented by an EAttribute but an EReference (both extend EStructuralFeature) and are accessible as the EClass’ elements, not attributes, even though from developer’s points of view they’re attributes of the owning class.
Let’s suppose that the book has the attribute name:
EStructuralFeature nameAttr = modelMetaData.getElement(bookEClass, null, "name");
The namespace is null because normally attributes/nested elements are not classified with a schema.
Here is how you would print the name and namespace URI of an attribute/element:
System.out.println("attr: " + modelMetaData.getNamespace(nameAttr) + ":" + nameAttr.getName()); // prints "null:name"
Tip 2: How to force EMF to serialize an object as an XML element instead of an XML attribute
Normally EMF stores simple Java properties as attributes of the XML element representing the owning class:
<b:Book b:xmlns="..." name="The Book of Songs" />
but you might prefer to have it rather as a nested element:
<b:Book b:xmlns="..."> <name>The Book of Songs</name> </b:Book>
To achieve that:
- Enable the save option OPTION_EXTENDED_META_DATA (so that extended meta data such as annotations and an XML map aren’t ignored)
- Tell EMF that you want this property to be stored as an element
- By attaching an eAnnotation to it (not shown)
- By supplying a XML Map with this information upon save
To enable the extended metadata:
Map<String, Object> saveOptions = new HashMap<String, Object>(); saveOptions.put(XMLResource.OPTION_EXTENDED_META_DATA, Boolean.TRUE);
According to some documentation the value should be an implementation of ExtendedMetaData, according to others Boolean.TRUE is the correct choice – I use the latter for it’s easier and works for me.
To tell EMF to write a property as an element when serailizing to XML:
import org.eclipse.emf.ecore.xmi.impl.*; ... EAttribute bookNameEAttribute = ...; // retrieved e.g. from meta data, see Tip 1 XMLMapImpl map = new XMLMapImpl(); XMLInfoImpl x = new XMLInfoImpl(); x.setXMLRepresentation(XMLInfoImpl.ELEMENT); map.add(bookNameEAttribute, x); saveOptions.put(XMLResource.OPTION_XML_MAP, map);
The XMLInfoImpl enables you to customize the namespace, name and representation of the element.
When saving you then just supply the save options:
EObject target = ...; org.eclipse.emf.ecore.resource.Resource outResource = ...; outResource.getContents().add(target); outResource.save(saveOptions);
Reference: the Redbook Eclipse Development using the Graphical Editing Framework and the Eclipse Modeling Framework, page 74, section 2.3.4