Making GEF and EMF work together [message #22371] |
Thu, 04 March 2004 11:59 |
Christian Brand Messages: 36 Registered: July 2009 Location: Walldorf/Germany |
Member |
|
|
What do you all think about an abstract layer (framework or/and library)
that helps developers to use GEF on top of EMF based data models?
We already thougt about that topic. Some prototypes have been created and
seem to work perfectly.
Examples:
Command Stack
Can be used as GEF command stack and as EMF command stack. Can work with
GEF and EMF commands. => EMF editing domain and GEF edit domain can work
on he same command stack instance. => no synchronisation problems
Edit Parts
Abstract edit part implementation representing an EMF object graphically.
Registers for changes in object and refreshes visuals automatically.
Overview Outline
Eclipse view that shows the whole 'picture'.
Further Ideas:
- Graphics model (EMF); layout contraints, colors, font, line width,...
- Generic property sheet support: supports attributes of 'graphids model'
- ...
Christian Brand
Christian Brand
SAP AG - Walldorf - Germany
|
|
|
|
Re: Making GEF and EMF work together [message #23395 is a reply to message #23250] |
Mon, 08 March 2004 08:06 |
Christian Brand Messages: 36 Registered: July 2009 Location: Walldorf/Germany |
Member |
|
|
Thank you for an elaborate answer.
Best regards,
Christian Brand
"Joe Winchester" <winchest@uk.ibm.com> wrote in message
news:4049153D.54C6AB78@uk.ibm.com...
> Hi Christian,
>
> > What do you all think about an abstract layer (framework or/and library)
> > that helps developers to use GEF on top of EMF based data models?
> > We already thougt about that topic. Some prototypes have been created
and
> > seem to work perfectly.
>
> This is a good idea and has been thought about several times before within
> IBM. For GEF it was felt that it should be model neutral, so having EMF
> there would limit its usages and GEF does a great job of finding the right
> balance. For the VE we use EMF and have abstracted a lot of the common
stuff
> into the org.eclipse.jem packages. At one point we did have examples of
> editors that used this and were just using raw EMF models. A lot of what
> goes on with edit policies is based around traversing and adding to a
single
> EMF relationship, and you're right about the command stack stuff (although
> for the VE we integrate with the JDT undo so the scenario of user changes
GUI
> then source then GUI is all undone correctly).
>
> The graphical stuff is harder to do in abstract. A lot of models just
want
> custom rendering, but an abstract impelementation could do some kind of
UML
> type relationship diagram. Another possibility is boxes within boxes for
> isContainment=true and lines between boxes for isContainment=false.
> EditPolicies could know what to do for dropping inside boxes and dragging
> lines could be done. However for the VE we decided somewhere along the
way
> that we needed to focus on a few goals and do them well rather than spead
> ourselves too thin and over-engineer. Therefore we are concentrated on
the
> out of the box GUI builder and also making this extensible for people
wanting
> to do other graphical runtime builders.
>
> So ... we do have the plugins and classes to do a lot of what you want,
> however it's not a priority for us to promote this just cause we're heads
> down on SWT and performance right now. However the VE is open-source so
if
> you want to get involved please join the ve newsgroup and it can be
discussed
> there further.
>
> Best regards,
>
> Joe Winchester
>
Christian Brand
SAP AG - Walldorf - Germany
|
|
|
|
Re: Making GEF and EMF work together [message #583731 is a reply to message #23250] |
Mon, 08 March 2004 08:06 |
Christian Brand Messages: 36 Registered: July 2009 Location: Walldorf/Germany |
Member |
|
|
Thank you for an elaborate answer.
Best regards,
Christian Brand
"Joe Winchester" <winchest@uk.ibm.com> wrote in message
news:4049153D.54C6AB78@uk.ibm.com...
> Hi Christian,
>
> > What do you all think about an abstract layer (framework or/and library)
> > that helps developers to use GEF on top of EMF based data models?
> > We already thougt about that topic. Some prototypes have been created
and
> > seem to work perfectly.
>
> This is a good idea and has been thought about several times before within
> IBM. For GEF it was felt that it should be model neutral, so having EMF
> there would limit its usages and GEF does a great job of finding the right
> balance. For the VE we use EMF and have abstracted a lot of the common
stuff
> into the org.eclipse.jem packages. At one point we did have examples of
> editors that used this and were just using raw EMF models. A lot of what
> goes on with edit policies is based around traversing and adding to a
single
> EMF relationship, and you're right about the command stack stuff (although
> for the VE we integrate with the JDT undo so the scenario of user changes
GUI
> then source then GUI is all undone correctly).
>
> The graphical stuff is harder to do in abstract. A lot of models just
want
> custom rendering, but an abstract impelementation could do some kind of
UML
> type relationship diagram. Another possibility is boxes within boxes for
> isContainment=true and lines between boxes for isContainment=false.
> EditPolicies could know what to do for dropping inside boxes and dragging
> lines could be done. However for the VE we decided somewhere along the
way
> that we needed to focus on a few goals and do them well rather than spead
> ourselves too thin and over-engineer. Therefore we are concentrated on
the
> out of the box GUI builder and also making this extensible for people
wanting
> to do other graphical runtime builders.
>
> So ... we do have the plugins and classes to do a lot of what you want,
> however it's not a priority for us to promote this just cause we're heads
> down on SWT and performance right now. However the VE is open-source so
if
> you want to get involved please join the ve newsgroup and it can be
discussed
> there further.
>
> Best regards,
>
> Joe Winchester
>
Christian Brand
SAP AG - Walldorf - Germany
|
|
|
Powered by
FUDForum. Page generated in 0.02711 seconds