Skip to main content



      Home
Home » Modeling » GMF (Graphical Modeling Framework) » Custom, non-XML serialization
Custom, non-XML serialization [message #158233] Sun, 04 November 2007 12:52 Go to next message
Eclipse UserFriend
Hi everyone,

I need to export the content of a user-created diagram to a file format very
different from the standard EMF XMI. This exported file needs information
from the domain model, the diagram model, and some external file-based data.

I would like to get some pointers on the best (i.e., easy and future-proof)
strategy. So far I figured out the following three alternatives:

* Manual parsing of the GMF-created xml files
This is problematic, because the standard path descriptions in these files
are not interpretable without knowledge of the domain model. A solution here
would be to customise the generation of paths.

* JET
This looks promising, but I have no clue how to use JET from within the GMF
program. I saw that the GMF-created code has an
"org.eclipse.emf.ecore.extension_parser" extension point, so I assume that
JET is already used within GMF to generate the domain model file? But then
where are the JET templates? And how can I plug in my own?

* From the object model
I could also load the Resource and use the EMF API to traverse the object
hierarchy and write the information into a file.

Which one is the best? And how would I get started?

Thanks a lot,
a>
Re: Custom, non-XML serialization [message #158240 is a reply to message #158233] Sun, 04 November 2007 13:08 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

André,

This isn't really so much a GMF question. GMF does support storing the
diagram description and the model data itself in separate files. Is
your external file based data an XML file? Is there an XML Schema which
describes it? If so, you could generate your model from that schema
and EMF will automatically be able to read and write it. If not, you
could specialize ResourceImpl.doLoad and doSave to read and write
exactly the format you want; of course you'll have to do all the parsing
and printing yourself. I don't think JET will help at all for this
particular problem. If you look at
https://bugs.eclipse.org/bugs/show_bug.cgi?id=206267 you'll see how I
created a prototype resource implementation that read and writes a
binary serialization rather than an XML/XMI one effectively just by
hooking into the doLoad and doSave methods.

A good answer depends quite a bit on what your file format it so you
might want to describe that a little more...


André Knörig wrote:
> Hi everyone,
>
> I need to export the content of a user-created diagram to a file
> format very different from the standard EMF XMI. This exported file
> needs information from the domain model, the diagram model, and some
> external file-based data.
>
> I would like to get some pointers on the best (i.e., easy and
> future-proof) strategy. So far I figured out the following three
> alternatives:
>
> * Manual parsing of the GMF-created xml files
> This is problematic, because the standard path descriptions in these
> files are not interpretable without knowledge of the domain model. A
> solution here would be to customise the generation of paths.
>
> * JET
> This looks promising, but I have no clue how to use JET from within
> the GMF program. I saw that the GMF-created code has an
> "org.eclipse.emf.ecore.extension_parser" extension point, so I assume
> that JET is already used within GMF to generate the domain model file?
> But then where are the JET templates? And how can I plug in my own?
>
> * From the object model
> I could also load the Resource and use the EMF API to traverse the
> object hierarchy and write the information into a file.
>
> Which one is the best? And how would I get started?
>
> Thanks a lot,
> a>
Re: Custom, non-XML serialization [message #158305 is a reply to message #158240] Mon, 05 November 2007 08:46 Go to previous messageGo to next message
Eclipse UserFriend
Hi Ed,

thanks for the quick response. The external data is a proprietary text
format that I am parsing manually. I had a look at the ResourceImpl you
supplied, but that's currently way beyond my level of understanding. ;)

So I am now approaching this by "simply" loading the model, traversing
it, and grabbing the correspoding data from the diagram and the external
file.
This leads to a new problem: I would like to parse the model and pull
some layout information corresponding to a node from the diagram. The
only way I have found so far to do this, is to use
viewer.findEditPartsForElement(elementIdStr, editPartClass). However,
not all of my elements have an id.
There must be a simpler way to do this, I assume?

Cheers!


Ed Merks schrieb:
> André,
>
> This isn't really so much a GMF question. GMF does support storing the
> diagram description and the model data itself in separate files. Is
> your external file based data an XML file? Is there an XML Schema which
> describes it? If so, you could generate your model from that schema
> and EMF will automatically be able to read and write it. If not, you
> could specialize ResourceImpl.doLoad and doSave to read and write
> exactly the format you want; of course you'll have to do all the parsing
> and printing yourself. I don't think JET will help at all for this
> particular problem. If you look at
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=206267 you'll see how I
> created a prototype resource implementation that read and writes a
> binary serialization rather than an XML/XMI one effectively just by
> hooking into the doLoad and doSave methods.
>
> A good answer depends quite a bit on what your file format it so you
> might want to describe that a little more...
>
>
> André Knörig wrote:
>> Hi everyone,
>>
>> I need to export the content of a user-created diagram to a file
>> format very different from the standard EMF XMI. This exported file
>> needs information from the domain model, the diagram model, and some
>> external file-based data.
>>
>> I would like to get some pointers on the best (i.e., easy and
>> future-proof) strategy. So far I figured out the following three
>> alternatives:
>>
>> * Manual parsing of the GMF-created xml files
>> This is problematic, because the standard path descriptions in these
>> files are not interpretable without knowledge of the domain model. A
>> solution here would be to customise the generation of paths.
>>
>> * JET
>> This looks promising, but I have no clue how to use JET from within
>> the GMF program. I saw that the GMF-created code has an
>> "org.eclipse.emf.ecore.extension_parser" extension point, so I assume
>> that JET is already used within GMF to generate the domain model file?
>> But then where are the JET templates? And how can I plug in my own?
>>
>> * From the object model
>> I could also load the Resource and use the EMF API to traverse the
>> object hierarchy and write the information into a file.
>>
>> Which one is the best? And how would I get started?
>>
>> Thanks a lot,
>> a>
Re: Custom, non-XML serialization [message #158344 is a reply to message #158305] Mon, 05 November 2007 09:26 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

André,

It really sounds to me like it would be best to design a ResourceImpl
that overrides doLoad and doSave to read and write your format. You
don't need all that crap that's in the binary resource impl, the point
of that was just to show how the doLoad and doSave hooks are used. You
effectively must be doing this loading and saving already, but somehow
it sounds like you are doing it in a more complex way. If you set that
up properly, the diagrams will be able to reference things in your
model's resource using standard EMF fragment paths. I'm not sure
exactly what's needed for the API you mention, but it might be the case
that for an EObject x, x.eResource().getURIFragment(x) is all that you need.


André Knörig wrote:
> Hi Ed,
>
> thanks for the quick response. The external data is a proprietary text
> format that I am parsing manually. I had a look at the ResourceImpl
> you supplied, but that's currently way beyond my level of
> understanding. ;)
>
> So I am now approaching this by "simply" loading the model, traversing
> it, and grabbing the correspoding data from the diagram and the
> external file.
> This leads to a new problem: I would like to parse the model and pull
> some layout information corresponding to a node from the diagram. The
> only way I have found so far to do this, is to use
> viewer.findEditPartsForElement(elementIdStr, editPartClass). However,
> not all of my elements have an id.
> There must be a simpler way to do this, I assume?
>
> Cheers!
>
>
> Ed Merks schrieb:
>> André,
>>
>> This isn't really so much a GMF question. GMF does support storing
>> the diagram description and the model data itself in separate files.
>> Is your external file based data an XML file? Is there an XML Schema
>> which describes it? If so, you could generate your model from that
>> schema and EMF will automatically be able to read and write it. If
>> not, you could specialize ResourceImpl.doLoad and doSave to read and
>> write exactly the format you want; of course you'll have to do all
>> the parsing and printing yourself. I don't think JET will help at
>> all for this particular problem. If you look at
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=206267 you'll see how I
>> created a prototype resource implementation that read and writes a
>> binary serialization rather than an XML/XMI one effectively just by
>> hooking into the doLoad and doSave methods.
>>
>> A good answer depends quite a bit on what your file format it so you
>> might want to describe that a little more...
>>
>>
>> André Knörig wrote:
>>> Hi everyone,
>>>
>>> I need to export the content of a user-created diagram to a file
>>> format very different from the standard EMF XMI. This exported file
>>> needs information from the domain model, the diagram model, and some
>>> external file-based data.
>>>
>>> I would like to get some pointers on the best (i.e., easy and
>>> future-proof) strategy. So far I figured out the following three
>>> alternatives:
>>>
>>> * Manual parsing of the GMF-created xml files
>>> This is problematic, because the standard path descriptions in these
>>> files are not interpretable without knowledge of the domain model. A
>>> solution here would be to customise the generation of paths.
>>>
>>> * JET
>>> This looks promising, but I have no clue how to use JET from within
>>> the GMF program. I saw that the GMF-created code has an
>>> "org.eclipse.emf.ecore.extension_parser" extension point, so I
>>> assume that JET is already used within GMF to generate the domain
>>> model file? But then where are the JET templates? And how can I plug
>>> in my own?
>>>
>>> * From the object model
>>> I could also load the Resource and use the EMF API to traverse the
>>> object hierarchy and write the information into a file.
>>>
>>> Which one is the best? And how would I get started?
>>>
>>> Thanks a lot,
>>> a>
Re: Custom, non-XML serialization [message #158393 is a reply to message #158305] Mon, 05 November 2007 13:28 Go to previous messageGo to next message
Eclipse UserFriend
Hello André,

I fully agree with Ed! I've tried to implement ResourceImpl for the proprietary
text file format once and implementation looks very straightforward..

-----------------
Alex Shatalin
Re: Custom, non-XML serialization [message #158401 is a reply to message #158344] Mon, 05 November 2007 13:30 Go to previous message
Eclipse UserFriend
Ed,

okay, maybe I was too timid. The ResourceImpl is obviously a good way to
place this.
The API call that you suggested works, too, but I still do not know how
I can get the layout/notation information for a semantic element. I
guess it's due to the MVC structure that it's easier the other way
around, but there should be some utility to do it this way, too?


Ed Merks schrieb:
> André,
>
> It really sounds to me like it would be best to design a ResourceImpl
> that overrides doLoad and doSave to read and write your format. You
> don't need all that crap that's in the binary resource impl, the point
> of that was just to show how the doLoad and doSave hooks are used. You
> effectively must be doing this loading and saving already, but somehow
> it sounds like you are doing it in a more complex way. If you set that
> up properly, the diagrams will be able to reference things in your
> model's resource using standard EMF fragment paths. I'm not sure
> exactly what's needed for the API you mention, but it might be the case
> that for an EObject x, x.eResource().getURIFragment(x) is all that you
> need.
>
>
> André Knörig wrote:
>> Hi Ed,
>>
>> thanks for the quick response. The external data is a proprietary text
>> format that I am parsing manually. I had a look at the ResourceImpl
>> you supplied, but that's currently way beyond my level of
>> understanding. ;)
>>
>> So I am now approaching this by "simply" loading the model, traversing
>> it, and grabbing the correspoding data from the diagram and the
>> external file.
>> This leads to a new problem: I would like to parse the model and pull
>> some layout information corresponding to a node from the diagram. The
>> only way I have found so far to do this, is to use
>> viewer.findEditPartsForElement(elementIdStr, editPartClass). However,
>> not all of my elements have an id.
>> There must be a simpler way to do this, I assume?
>>
>> Cheers!
>>
>>
>> Ed Merks schrieb:
>>> André,
>>>
>>> This isn't really so much a GMF question. GMF does support storing
>>> the diagram description and the model data itself in separate files.
>>> Is your external file based data an XML file? Is there an XML Schema
>>> which describes it? If so, you could generate your model from that
>>> schema and EMF will automatically be able to read and write it. If
>>> not, you could specialize ResourceImpl.doLoad and doSave to read and
>>> write exactly the format you want; of course you'll have to do all
>>> the parsing and printing yourself. I don't think JET will help at
>>> all for this particular problem. If you look at
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=206267 you'll see how I
>>> created a prototype resource implementation that read and writes a
>>> binary serialization rather than an XML/XMI one effectively just by
>>> hooking into the doLoad and doSave methods.
>>>
>>> A good answer depends quite a bit on what your file format it so you
>>> might want to describe that a little more...
>>>
>>>
>>> André Knörig wrote:
>>>> Hi everyone,
>>>>
>>>> I need to export the content of a user-created diagram to a file
>>>> format very different from the standard EMF XMI. This exported file
>>>> needs information from the domain model, the diagram model, and some
>>>> external file-based data.
>>>>
>>>> I would like to get some pointers on the best (i.e., easy and
>>>> future-proof) strategy. So far I figured out the following three
>>>> alternatives:
>>>>
>>>> * Manual parsing of the GMF-created xml files
>>>> This is problematic, because the standard path descriptions in these
>>>> files are not interpretable without knowledge of the domain model. A
>>>> solution here would be to customise the generation of paths.
>>>>
>>>> * JET
>>>> This looks promising, but I have no clue how to use JET from within
>>>> the GMF program. I saw that the GMF-created code has an
>>>> "org.eclipse.emf.ecore.extension_parser" extension point, so I
>>>> assume that JET is already used within GMF to generate the domain
>>>> model file? But then where are the JET templates? And how can I plug
>>>> in my own?
>>>>
>>>> * From the object model
>>>> I could also load the Resource and use the EMF API to traverse the
>>>> object hierarchy and write the information into a file.
>>>>
>>>> Which one is the best? And how would I get started?
>>>>
>>>> Thanks a lot,
>>>> a>
Previous Topic:Triangle: How to reuse OR how to define connection points for custom figure
Next Topic:Customizing EditPart
Goto Forum:
  


Current Time: Fri May 16 06:30:38 EDT 2025

Powered by FUDForum. Page generated in 0.06411 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top