Home » Modeling » Graphiti » Couple Graphiti Editor with XText DSL
| Couple Graphiti Editor with XText DSL [message #947535] |
Wed, 17 October 2012 07:04  |
 Markus Knoop
Messages: 14
Registered: January 2012 |
Junior Member |
|
|
Hello,
i have a question to both technologies. I created a graphiti editor to model a processes decription. I created a grammar for a Xtext DSL to decribe the process in text format. Now i want to couple both technologies. The graphiti editor should save the process description direct inside the own dsl file (the graphical content will be saved in a separate file). So the user will be able to use both technology to decribe a process.
By create a new process decription with the graphiti editor, i create now a normal resource of type Resource. So my first try was to replace the Resoruce-type by an XtextResource-type which result in SAXParser-Exceptions. I would expected to define somewhere the target grammar, but i didn't find any hint for this.
Did anyone have an example for this? How could i create a XtextResource and save directly DSL-Elements inside this?
Regards,
Markus
[Updated on: Wed, 17 October 2012 07:09] Report message to a moderator |
|
|
| Re: Couple Graphiti Editor with XText DSL [message #948009 is a reply to message #947535] |
Wed, 17 October 2012 17:13  |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
Hi,
I'm interested in this topic and have considered several options,
without coming to a conclusion.
Option 1 is the one you describe, where the diagram refers directly to
DSL content in an XtextResource and both are contained in the same
ResourceSet. However, I think an XtextResource must be within a special
XtextResourceSet and I don't think this resource can be used with the
transactional editing domain that the diagram editor uses.
Option 2 is having two ResourceSets, one for the diagram and core model
and one for the DSL content. Changes in one have to be refleced in the
other, and that is tricky. You may be able to record diagram editor
changes (to the core model), translate these to work on the DSL content
and replay them. Another variant is to serialize the core model from the
diagram editor, whenever you want to edit it as text. The other way
around, you'll have to merge the DSL content with the core model and
update the diagram (corresponding to serializing as a diagram, but far
more difficult).
Option 3 is to use an embedded editor in the properties of the diagram
editor and only allow textual editing of parts that are easy (enough) to
sync. E.g. parts that anyway aren't visualized in the diagram or for
which the layout is easy to regenerate (complete update of a diagram shape).
Option 4 is to only allow linking between the models, but no overlapping
containment. E.g. a diagram shape can refer to a process that's
completely described using the DSL and never edited as a diagram. You
may be able to support transitioning between the two, but without
automatic and smooth syncing.
In the program for EclipseCon Europe I saw mention of a presentation of
the sphinx project, which seems to try to make this easier, but I think
a completely general solution is difficult.
At this point I have only started on option 3, but I hope to explore
some of the others. Please report on your progress, I'm sure others are
struggling with the same issues (hence I'm cross-posting to the EMF and
TMF groups).
Hallvard
On 17.10.12 00.04, Markus Knoop wrote:
> Hello,
>
> i have a question to both technologies. I created a graphiti editor to
> model a processes decription. I created a grammar for a Xtext DSL to
> decribe the process in text format. Now i want to couple both
> technologies. The graphiti editor should save the process description
> direct inside the own dsl file (the graphical content will be saved in a
> separate file). So the user will be able to use both technology to
> decribe a process.
>
> By create a new process decription with the graphiti editor, i create
> now a normal resource of type Resource. So my first try was to replace
> the Resoruce-type by an XtextResource-type which result in
> SAXParser-Exceptions. Did anyone have an example for this? How could i
> create a XtextResource and save directly DSL-Elements inside this?
>
> Regards,
> Markus
|
|
|
| Re: Couple Graphiti Editor with XText DSL [message #948465 is a reply to message #948009] |
Thu, 18 October 2012 04:02 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Hallvard,
Comments below.
On 17/10/2012 7:15 PM, Hallvard Trætteberg wrote:
> Hi,
>
> I'm interested in this topic and have considered several options,
> without coming to a conclusion.
>
> Option 1 is the one you describe, where the diagram refers directly to
> DSL content in an XtextResource and both are contained in the same
> ResourceSet. However, I think an XtextResource must be within a
> special XtextResourceSet and I don't think this resource can be used
> with the transactional editing domain that the diagram editor uses.
I'm not sure about the transactional thing, but it doesn't need to be a
special XtextResourceSet. For example, the sample reflective editor is
able to use Xcore resources in a normal resource set. In that case, you
definitely need to inject an IJavaProjectProvider
public Class<? extends IJavaProjectProvider> bindIJavaProjectProvider()
{
return XcoreJavaProjectProvider.class;
}
>
> Option 2 is having two ResourceSets, one for the diagram and core
> model and one for the DSL content. Changes in one have to be refleced
> in the other, and that is tricky. You may be able to record diagram
> editor changes (to the core model), translate these to work on the DSL
> content and replay them. Another variant is to serialize the core
> model from the diagram editor, whenever you want to edit it as text.
> The other way around, you'll have to merge the DSL content with the
> core model and update the diagram (corresponding to serializing as a
> diagram, but far more difficult).
>
> Option 3 is to use an embedded editor in the properties of the diagram
> editor and only allow textual editing of parts that are easy (enough)
> to sync. E.g. parts that anyway aren't visualized in the diagram or
> for which the layout is easy to regenerate (complete update of a
> diagram shape).
>
> Option 4 is to only allow linking between the models, but no
> overlapping containment. E.g. a diagram shape can refer to a process
> that's completely described using the DSL and never edited as a
> diagram. You may be able to support transitioning between the two, but
> without automatic and smooth syncing.
Yes, allowing editing of the model via the diagram is rather
disruptive. The formatter is currently far from ideal and will tend to
make a mess of the source. I still need to explore how the Ecore Tools
graphical editor could support Xcore; but that's a GMF problem, not a
Graphiti one...
>
> In the program for EclipseCon Europe I saw mention of a presentation
> of the sphinx project, which seems to try to make this easier, but I
> think a completely general solution is difficult.
>
> At this point I have only started on option 3, but I hope to explore
> some of the others. Please report on your progress, I'm sure others
> are struggling with the same issues (hence I'm cross-posting to the
> EMF and TMF groups).
Yes, it will be interesting to here about progress and experience!
>
> Hallvard
>
> On 17.10.12 00.04, Markus Knoop wrote:
>> Hello,
>>
>> i have a question to both technologies. I created a graphiti editor to
>> model a processes decription. I created a grammar for a Xtext DSL to
>> decribe the process in text format. Now i want to couple both
>> technologies. The graphiti editor should save the process description
>> direct inside the own dsl file (the graphical content will be saved in a
>> separate file). So the user will be able to use both technology to
>> decribe a process.
>>
>> By create a new process decription with the graphiti editor, i create
>> now a normal resource of type Resource. So my first try was to replace
>> the Resoruce-type by an XtextResource-type which result in
>> SAXParser-Exceptions. Did anyone have an example for this? How could i
>> create a XtextResource and save directly DSL-Elements inside this?
>>
>> Regards,
>> Markus
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Couple Graphiti Editor with XText DSL [message #948556 is a reply to message #948465] |
Thu, 18 October 2012 06:23 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
On 17.10.12 21.02, Ed Merks wrote:
> Hallvard,
>
> Comments below.
>
> On 17/10/2012 7:15 PM, Hallvard Trætteberg wrote:
>>
>> Option 1 is the one you describe, where the diagram refers directly to
>> DSL content in an XtextResource and both are contained in the same
>> ResourceSet. However, I think an XtextResource must be within a
>> special XtextResourceSet and I don't think this resource can be used
>> with the transactional editing domain that the diagram editor uses.
> I'm not sure about the transactional thing, but it doesn't need to be a
> special XtextResourceSet. For example, the sample reflective editor is
> able to use Xcore resources in a normal resource set. In that case, you
> definitely need to inject an IJavaProjectProvider
>
> public Class<? extends IJavaProjectProvider> bindIJavaProjectProvider()
> {
> return XcoreJavaProjectProvider.class;
> }
Hm, you are right. But I guess the problems will be the same as for
option 2.
>> Option 3 is to use an embedded editor in the properties of the diagram
>> editor and only allow textual editing of parts that are easy (enough)
>> to sync. E.g. parts that anyway aren't visualized in the diagram or
>> for which the layout is easy to regenerate (complete update of a
>> diagram shape).
THe Obeo people seems to have succeeded in using this variant, judging
from this link: http://twitpic.com/1tnjvx
There's also
http://code.google.com/a/eclipselabs.org/p/xtext-forms-integration, but
they don't need to be able to update a diagram as they use forms for
alternative editing.
I'm going to take a look at these solutions, to see if they allow
serializing and parsing arbitrary objects. Ideally, you should be able
to serialize some object X, limit the visible/editable part of the
editor to only be region of text corresponding to a certain feature F of
X, parse the text into a new X' and then update the F of (the original)
X based on F of X'.
>> Option 4 is to only allow linking between the models, but no
>> overlapping containment. E.g. a diagram shape can refer to a process
>> that's completely described using the DSL and never edited as a
>> diagram. You may be able to support transitioning between the two, but
>> without automatic and smooth syncing.
> Yes, allowing editing of the model via the diagram is rather
> disruptive. The formatter is currently far from ideal and will tend to
> make a mess of the source. I still need to explore how the Ecore Tools
> graphical editor could support Xcore; but that's a GMF problem, not a
> Graphiti one...
I would guess the solution for how to manage the resource(s) will be
similar, but how to update the diagram and integrate the editor will be
different.
Hallvard
|
|
|
Goto Forum:
Current Time: Thu Apr 25 06:48:22 GMT 2024
Powered by FUDForum. Page generated in 0.03219 seconds |
] 
Search
Help
Register
Login
Home
