Home » Modeling » EMF » One XML document
| | |
| Re: One XML document [message #389491 is a reply to message #389481] |
Thu, 25 November 2004 12:00   |
 Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
Will,
To either copy or move, you need to collect/find/determine all the root
objects of all the separate resources that you want to save into a
single resource. Suppose you've collected them into a Collection x,
then you can do either newResource.getContents.addAll(x) or
newResource.getContents().addAll(EcoreUtil.copyAll(x)). The former will
move the roots from their current resources to the new resource while
the later will copy all the objects (as a group, properly preserving
cross references between them) and will place them in the new resource.
(Note that if you don't use a resource set to load a resource that has
cross document references, demand load of the referenced documents will
not work, so all proxies will fail to resolve.)
Will wrote:
> Thanks for your help Ed,
>
> I'm still unclear about how to "copy" or "move" all my objects to one
> resource. I tried the following (see code below), but it only
> copies the root object (probably because the other objects are in the
> different files). Do I have to manually traverse all the objects, or
> is there a "CopyAll" or "MoveAll" type command.
>
> Here is the code I have:
>
> Resource resource = new XMIResourceImpl(ecoreURI);
> try
> {
> resource.load(Collections.EMPTY_MAP);
> Resource newResource = new XMIResourceImpl(newEcoreURI);
> for (Iterator iter = resource.getAllContents(); iter.hasNext();)
> {
> EObject eObject = (EObject) iter.next();
> newResource.getContents().add(EcoreUtil.copy(eObject));
> }
> newResource.save(Collections.EMPTY_MAP);
> }
>
> Thanks,
>
> - Will
>
>
>
> Ed Merks wrote:
>
>> Will,
>
>
>> The easiest way is to move them into one resource and to save that.
>> You could also use EcoreUtil.copy to copy everything and then to put
>> the copies into one new resource. Note that only an XMIResourceImpl
>> will let you save more than one object in the
>> Resource.getContents(). It's even possible to save each resource
>> separately into a memory buffer and to compose the text into a single
>> stream, but only if the separate files don't cross reference each
>> other (since the references will need to look like same document
>> references not cross document references). The implementation of
>> org.eclipse.emf.ecore.sdo.util.DataGraphResourceFactoryImpl shows how
>> a DataGraph's serialization is specialized to be composed from the
>> contents of multiple resources that to do cross reference each other;
>> that would be the fanciest way...
>
>
>
>> Will wrote:
>
>
>>> I have created EMF model objects that serialize into separate
>>> resources (and therefore separate files). And this is how I want to
>>> serialize and save my project.
>>>
>>> However, I would also (at times) like to be able to create an XML
>>> document that represents the whole model state in ONE xml document.
>>>
>>> What would be the easiest way to get the XML of the entire project,
>>> even though it spans multiple files?
>>>
>>>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: One XML document [message #389600 is a reply to message #389491] |
Tue, 30 November 2004 00:04 |
Will
Messages: 48
Registered: July 2009 |
Member |
|
|
In response to your feedback, I created a piece of code that loads the
main resource, and then recursively loops thought the eCrossReferences to
find other objects to add to the resource. After creating a Collection of
objects to add, I use the "addAll(Collection)" method to add to a new
resource, and save the resource .... And for the most part this works (in
that it puts all the resources into one resource)
However, this is not quite what I need, because there is no implied
context information. For example, I get this:
<Project name="ImProject" domain="/1" />
<Domain name="Modeler Workspace" domainItems="/2 /3" />
<DomainItem name="foo" />
<DomainItem name="bar" />
When, what I need is this:
<Project name="ImProject">
<Domain name="Modeler Workspace" />
<DomainItem name="foo"/>
<DomainItem name="bar"/>
</Domain>
</Project>
So at this point, unless you have any more pointers, I'm thinking I'll
need to maunually travers all the EObject and use a parser to create the
"implied" containment nodes that I need?!?!? ... Is this correct?
Also, is there an way to pull the XML string out? ... That way I could use
this kind of logic:
If (the string contains an "href" to another file) {
... insert the referenced file XML string }
else {
... just insert the XML string itself }
Thanks in advance for your help,
- Will
Ed Merks wrote:
> Will,
> To either copy or move, you need to collect/find/determine all the root
> objects of all the separate resources that you want to save into a
> single resource. Suppose you've collected them into a Collection x,
> then you can do either newResource.getContents.addAll(x) or
> newResource.getContents().addAll(EcoreUtil.copyAll(x)). The former will
> move the roots from their current resources to the new resource while
> the later will copy all the objects (as a group, properly preserving
> cross references between them) and will place them in the new resource.
> (Note that if you don't use a resource set to load a resource that has
> cross document references, demand load of the referenced documents will
> not work, so all proxies will fail to resolve.)
> Will wrote:
>> Thanks for your help Ed,
>>
>> I'm still unclear about how to "copy" or "move" all my objects to one
>> resource. I tried the following (see code below), but it only
>> copies the root object (probably because the other objects are in the
>> different files). Do I have to manually traverse all the objects, or
>> is there a "CopyAll" or "MoveAll" type command.
>>
>> Here is the code I have:
>>
>> Resource resource = new XMIResourceImpl(ecoreURI);
>> try
>> {
>> resource.load(Collections.EMPTY_MAP);
>> Resource newResource = new XMIResourceImpl(newEcoreURI);
>> for (Iterator iter = resource.getAllContents(); iter.hasNext();)
>> {
>> EObject eObject = (EObject) iter.next();
>> newResource.getContents().add(EcoreUtil.copy(eObject));
>> }
>> newResource.save(Collections.EMPTY_MAP);
>> }
>>
>> Thanks,
>>
>> - Will
>>
>>
>>
>> Ed Merks wrote:
>>
>>> Will,
>>
>>
>>> The easiest way is to move them into one resource and to save that.
>>> You could also use EcoreUtil.copy to copy everything and then to put
>>> the copies into one new resource. Note that only an XMIResourceImpl
>>> will let you save more than one object in the
>>> Resource.getContents(). It's even possible to save each resource
>>> separately into a memory buffer and to compose the text into a single
>>> stream, but only if the separate files don't cross reference each
>>> other (since the references will need to look like same document
>>> references not cross document references). The implementation of
>>> org.eclipse.emf.ecore.sdo.util.DataGraphResourceFactoryImpl shows how
>>> a DataGraph's serialization is specialized to be composed from the
>>> contents of multiple resources that to do cross reference each other;
>>> that would be the fanciest way...
>>
>>
>>
>>> Will wrote:
>>
>>
>>>> I have created EMF model objects that serialize into separate
>>>> resources (and therefore separate files). And this is how I want to
>>>> serialize and save my project.
>>>>
>>>> However, I would also (at times) like to be able to create an XML
>>>> document that represents the whole model state in ONE xml document.
>>>>
>>>> What would be the easiest way to get the XML of the entire project,
>>>> even though it spans multiple files?
>>>>
>>>>
>>
>>
|
|
|
| Re: One XML document [message #389603 is a reply to message #389600] |
Tue, 30 November 2004 10:47 |
Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
Will,
One possible approach to try is to override XMLSaveImpl to create a
derived XMLSaveImpl.Lookup (during init()) that overrides featureKind()
to return a result that makes the non-containment references look like
containment references.
You can use Resource.save(x, null), where x is a ByteArrayOutputStream,
to create an in memory serialization.
Will wrote:
> In response to your feedback, I created a piece of code that loads the
> main resource, and then recursively loops thought the eCrossReferences
> to find other objects to add to the resource. After creating a
> Collection of objects to add, I use the "addAll(Collection)" method to
> add to a new resource, and save the resource .... And for the most
> part this works (in that it puts all the resources into one resource)
>
> However, this is not quite what I need, because there is no implied
> context information. For example, I get this:
>
> <Project name="ImProject" domain="/1" />
> <Domain name="Modeler Workspace" domainItems="/2 /3" />
> <DomainItem name="foo" />
> <DomainItem name="bar" />
>
> When, what I need is this:
>
> <Project name="ImProject">
> <Domain name="Modeler Workspace" />
> <DomainItem name="foo"/>
> <DomainItem name="bar"/>
> </Domain>
> </Project>
>
> So at this point, unless you have any more pointers, I'm thinking I'll
> need to maunually travers all the EObject and use a parser to create
> the "implied" containment nodes that I need?!?!? ... Is this correct?
>
> Also, is there an way to pull the XML string out? ... That way I could
> use this kind of logic:
>
> If (the string contains an "href" to another file) {
> ... insert the referenced file XML string }
> else {
> ... just insert the XML string itself }
>
> Thanks in advance for your help,
>
> - Will
>
>
>
>
>
> Ed Merks wrote:
>
>> Will,
>
>
>> To either copy or move, you need to collect/find/determine all the
>> root objects of all the separate resources that you want to save into
>> a single resource. Suppose you've collected them into a Collection
>> x, then you can do either newResource.getContents.addAll(x) or
>> newResource.getContents().addAll(EcoreUtil.copyAll(x)). The former
>> will move the roots from their current resources to the new resource
>> while the later will copy all the objects (as a group, properly
>> preserving cross references between them) and will place them in the
>> new resource.
>
>
>> (Note that if you don't use a resource set to load a resource that
>> has cross document references, demand load of the referenced
>> documents will not work, so all proxies will fail to resolve.)
>
>
>
>> Will wrote:
>
>
>>> Thanks for your help Ed,
>>>
>>> I'm still unclear about how to "copy" or "move" all my objects to
>>> one resource. I tried the following (see code below), but it only
>>> copies the root object (probably because the other objects are in
>>> the different files). Do I have to manually traverse all the
>>> objects, or is there a "CopyAll" or "MoveAll" type command.
>>>
>>> Here is the code I have:
>>>
>>> Resource resource = new XMIResourceImpl(ecoreURI);
>>> try
>>> {
>>> resource.load(Collections.EMPTY_MAP);
>>> Resource newResource = new XMIResourceImpl(newEcoreURI);
>>> for (Iterator iter = resource.getAllContents();
>>> iter.hasNext();)
>>> {
>>> EObject eObject = (EObject) iter.next();
>>> newResource.getContents().add(EcoreUtil.copy(eObject));
>>> }
>>> newResource.save(Collections.EMPTY_MAP);
>>> }
>>>
>>> Thanks,
>>>
>>> - Will
>>>
>>>
>>>
>>> Ed Merks wrote:
>>>
>>>> Will,
>>>
>>>
>>>
>>>> The easiest way is to move them into one resource and to save
>>>> that. You could also use EcoreUtil.copy to copy everything and
>>>> then to put the copies into one new resource. Note that only an
>>>> XMIResourceImpl will let you save more than one object in the
>>>> Resource.getContents(). It's even possible to save each resource
>>>> separately into a memory buffer and to compose the text into a
>>>> single stream, but only if the separate files don't cross
>>>> reference each other (since the references will need to look like
>>>> same document references not cross document references). The
>>>> implementation of
>>>> org.eclipse.emf.ecore.sdo.util.DataGraphResourceFactoryImpl shows
>>>> how a DataGraph's serialization is specialized to be composed from
>>>> the contents of multiple resources that to do cross reference each
>>>> other; that would be the fanciest way...
>>>
>>>
>>>
>>>
>>>> Will wrote:
>>>
>>>
>>>
>>>>> I have created EMF model objects that serialize into separate
>>>>> resources (and therefore separate files). And this is how I want
>>>>> to serialize and save my project.
>>>>>
>>>>> However, I would also (at times) like to be able to create an XML
>>>>> document that represents the whole model state in ONE xml document.
>>>>>
>>>>> What would be the easiest way to get the XML of the entire
>>>>> project, even though it spans multiple files?
>>>>>
>>>>>
>>>
>>>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
| Re: One XML document [message #389641 is a reply to message #389640] |
Wed, 01 December 2004 14:52 |
Aleksander Bandelj
Messages: 98
Registered: July 2009 |
Member |
|
|
Ok, so I have to take care of cycles myself. So, first time I encounter
a reference during save, I would serialize it as containment, second
time as an idref.
The approach with overriding featureKind fails even on tree structures.
Consider two nodes, connected by edge. Code below would force node
object to contain edge and edge to contain node. Node 1 would try to
write out edge, which would try to write out nodes 1 and 2, which would
write out edge ... you get the idea.
So, I'll try to override save* methods in Resource. Do you have some
other suggestion ?
Ed Merks wrote:
> Aleksander,
>
> I haven't tried it myself, but this is kind of like what I had in mind,
> although I was expecting that you would do this only for certain
> features not for all features. What seems not to be working well?
>
> Definitely you need to be careful to do this only if the implied
> containment graph is a tree...
>
>
> Aleksander Bandelj wrote:
>
>> I've overriden featureKind as follows:
>>
>> protected int featureKind(EStructuralFeature feat) {
>> int kind= super.featureKind(feat);
>> switch (kind) {
>> case OBJECT_HREF_MANY :
>> return OBJECT_CONTAIN_MANY;
>> case OBJECT_HREF_SINGLE :
>> return OBJECT_CONTAIN_SINGLE;
>> case OBJECT_HREF_SINGLE_UNSETTABLE :
>> return OBJECT_CONTAIN_SINGLE_UNSETTABLE;
>> case OBJECT_HREF_MANY_UNSETTABLE :
>> return OBJECT_CONTAIN_MANY_UNSETTABLE;
>> }
>> return kind;
>> }
>>
>> But it doesn't seem to work well. Could you elaborate on which
>> reference kinds must be replaced ? How about potential infinite
>> recursion during object graph traversal ?
>>
>> Ed Merks wrote:
|
|
|
| Re: One XML document [message #389643 is a reply to message #389641] |
Wed, 01 December 2004 16:04 |
Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
Aleksander,
I don't know enough about your model structure to anticipate what issues
you might encounter, nor do I know what stylistic constraints you have
for how the serialized result should look, e.g., your original combined
result is perfectly good, but it just doesn't look the way you want.
This notion of serializing for real on first visit and serializing a
reference the next time doesn't sound very good to me. It will produce
very unpredictable results (that can't be described by a schema). But I
don't have much else to suggest...
Aleksander Bandelj wrote:
> Ok, so I have to take care of cycles myself. So, first time I
> encounter a reference during save, I would serialize it as
> containment, second time as an idref.
>
> The approach with overriding featureKind fails even on tree
> structures. Consider two nodes, connected by edge. Code below would
> force node object to contain edge and edge to contain node. Node 1
> would try to write out edge, which would try to write out nodes 1 and
> 2, which would write out edge ... you get the idea.
>
> So, I'll try to override save* methods in Resource. Do you have some
> other suggestion ?
>
> Ed Merks wrote:
>
>> Aleksander,
>>
>> I haven't tried it myself, but this is kind of like what I had in
>> mind, although I was expecting that you would do this only for
>> certain features not for all features. What seems not to be working
>> well?
>>
>> Definitely you need to be careful to do this only if the implied
>> containment graph is a tree...
>>
>>
>> Aleksander Bandelj wrote:
>>
>>> I've overriden featureKind as follows:
>>>
>>> protected int featureKind(EStructuralFeature feat) {
>>> int kind= super.featureKind(feat);
>>> switch (kind) {
>>> case OBJECT_HREF_MANY :
>>> return OBJECT_CONTAIN_MANY;
>>> case OBJECT_HREF_SINGLE :
>>> return OBJECT_CONTAIN_SINGLE;
>>> case OBJECT_HREF_SINGLE_UNSETTABLE :
>>> return OBJECT_CONTAIN_SINGLE_UNSETTABLE;
>>> case OBJECT_HREF_MANY_UNSETTABLE :
>>> return OBJECT_CONTAIN_MANY_UNSETTABLE;
>>> }
>>> return kind;
>>> }
>>>
>>> But it doesn't seem to work well. Could you elaborate on which
>>> reference kinds must be replaced ? How about potential infinite
>>> recursion during object graph traversal ?
>>>
>>> Ed Merks wrote:
>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Goto Forum:
Current Time: Thu Apr 18 15:39:10 GMT 2024
Powered by FUDForum. Page generated in 0.02398 seconds |
] 
Search
Help
Register
Login
Home
