Single class, multiple lines in XML represenation. [message #1830798] |
Tue, 04 August 2020 04:31  |
Eclipse User |
|
|
|
So in my model I have some metadata that needs to be on multiple lines. The class is called name (which can be a child of itself) and the structure in a model might look something like this (without the numbers)
(1)
Name Key = "Description" Value = "..."
Name Key = "Project" Value = "..."
Name Key = "Author" Value = "..."
(2)
Name Key = "History"
Name Key = "Version" Value = "..."
Name Key = "Date" Value = "..."
This obviously takes up 6 lines in the XML representation of my model.
I'm wondering if its possible to instead of having multiple children just have some Metadata class, that has all the above Key's as attributes, and would produce the same XML representation.
For example
Metadata Description = "..." Project = "..." Date = "..."
or instead if its not possible to capture the nesting behaviour with a single class, instead have a class for (1) and a class for (2) like
Metadata Description = "..." Project = "..."
History Version = "..." Date = "..."
Thanks
|
|
|
Re: Single class, multiple lines in XML represenation. [message #1830834 is a reply to message #1830798] |
Tue, 04 August 2020 23:48  |
Eclipse User |
|
|
|
The short answer is no. In general, the names of elements and attributes in the XML serialization correspond to the names of features (references and attributes) in the Ecore model. They do not ever correspond to the value of any instance data.
The long answer is, anything is possible if you specialize the serialization and deserialization yourself. Certainly XML Schema has the concept of an attribute wildcard and this maps to an EAttribute of type FeatureMap in the Ecore model. But that's a complex API to use...
Given you've not actually described your model in enough detail that I know what (1) and (2) correspond to, it's hard to say much of anything concrete. In any case, nesting in the serialization only comes from containment references in the model.
|
|
|
Powered by
FUDForum. Page generated in 0.06438 seconds