Home » Eclipse Projects » GEF » Arguments contra GMF and pro GEF
| Arguments contra GMF and pro GEF [message #248530] |
Wed, 22 April 2009 11:04  |
Eclipse User |
|
|
|
Originally posted by: juergen.scheffler.gmx.de
Hi,
for a work I need some arguments why people use GEF for there projects
instead of using GMF.
I know that GEF focuses on the graphical editing and GMF on model and
editing, but ifyou use GEF you will also need a model, so what ware the
main reason for using GEF instead of GMF ?
thx
Jürgen
|
|
| |
| Re: Arguments contra GMF and pro GEF [message #248607 is a reply to message #248530] |
Fri, 24 April 2009 06:12  |
| Eclipse User |
|
|
|
Jürgen,
actually GMF is using GEF, so GMF = GEF + more. The question is: Do you
need that "more". GMF consists of two parts: a tool for automatically
generating GEF or GMF based editors (actually you can choose to only
generate GEF based editors, at least this was an option some time ago,
I don't know the latest version). Using the generator tool is good if
you are developing more or less a standard editor and if you do not
think you have to add some weird things.
But GMF also comes with a runtime framework adding a lot of things to
GEF. IMHO the two most interesting features are: a notation model and a
service/provider-architecture for extending editors via the plugin
mechanism. If someone writes that GEF doesn't separates models from
view, (s)he probably is referring to the notation model (because GEF
uses the MVC model and has a very clear separation between these parts).
GMF requires EMF based models, while GEF can work with EMF based
models, but you can use any model implementation you'd like (the only
thing your model should provide is some sort of observer-pattern). So
if your model is not EMF based and you do not want to re-implement it
vai EMF (which is often not a big issue), better use GEF.
If your model is based on EMF, the question is whether you need a
notation model. The notation model contains all information about the
position and size of elements, the colors etc. This kind of information
is often not already present in the models to be edited. If you model
(that is the "raw" data you want to present) already contains that
data, you maybe don't want to use another notation model and add new
complexity.
The provider/service stuff is quite nice if you have to implement
variations of your editor, if you want to modify existing (GMF-based)
editors and so on. If you only want to build one single editor, you may
use only GEF to avoid complexity.
Frankly, I know GEF pretty well and I'm sometimes faster implementing
the editor from scratch with GEF instead of using that not very
user-friendly GMF generation tool. And GMF really adds lots of
complexity. For example, I can create a basic editor with about 20
classes, while the GMF generated code consists of 80 classes. OK, the
GMF generated stuff is more powerful, but if you don't need all that
functionality, it is only a burden. On the other hand I really like
using GMF's notation model, because implementing this by yourself is
not as easy as it sounds.
Cheers
Jens
|
|
|
| Re: Arguments contra GMF and pro GEF [message #248618 is a reply to message #248607] |
Fri, 24 April 2009 08:23 |
| Eclipse User |
|
|
|
Originally posted by: juergen.scheffler.gmx.de
Jens v.P. schrieb:
> Jürgen,
>
> actually GMF is using GEF, so GMF = GEF + more. The question is: Do you
> need that "more". GMF consists of two parts: a tool for automatically
> generating GEF or GMF based editors (actually you can choose to only
> generate GEF based editors, at least this was an option some time ago, I
> don't know the latest version). Using the generator tool is good if you
> are developing more or less a standard editor and if you do not think
> you have to add some weird things.
>
> But GMF also comes with a runtime framework adding a lot of things to
> GEF. IMHO the two most interesting features are: a notation model and a
> service/provider-architecture for extending editors via the plugin
> mechanism. If someone writes that GEF doesn't separates models from
> view, (s)he probably is referring to the notation model (because GEF
> uses the MVC model and has a very clear separation between these parts).
>
> GMF requires EMF based models, while GEF can work with EMF based models,
> but you can use any model implementation you'd like (the only thing your
> model should provide is some sort of observer-pattern). So if your model
> is not EMF based and you do not want to re-implement it vai EMF (which
> is often not a big issue), better use GEF.
>
> If your model is based on EMF, the question is whether you need a
> notation model. The notation model contains all information about the
> position and size of elements, the colors etc. This kind of information
> is often not already present in the models to be edited. If you model
> (that is the "raw" data you want to present) already contains that data,
> you maybe don't want to use another notation model and add new complexity.
>
> The provider/service stuff is quite nice if you have to implement
> variations of your editor, if you want to modify existing (GMF-based)
> editors and so on. If you only want to build one single editor, you may
> use only GEF to avoid complexity.
>
> Frankly, I know GEF pretty well and I'm sometimes faster implementing
> the editor from scratch with GEF instead of using that not very
> user-friendly GMF generation tool. And GMF really adds lots of
> complexity. For example, I can create a basic editor with about 20
> classes, while the GMF generated code consists of 80 classes. OK, the
> GMF generated stuff is more powerful, but if you don't need all that
> functionality, it is only a burden. On the other hand I really like
> using GMF's notation model, because implementing this by yourself is not
> as easy as it sounds.
>
> Cheers
>
> Jens
>
Thx Jens, how did you become such a GEF/GMF professional? I put lot of
self-studies to GEF and still only know a small part of it. f.e. where
can I learn to use the service/provider meanism?
@notation model? So GMF generates this?! Does it copy a model elements
and give them only view specific attributes? ATM I got f.e. coordiantes
as attributes in my EMF model that I use for GEF.
At GEF I can store/serialize the view model as xml. Well its not a real
model, but its separated from the domain model. What poster 1 meant = I
dont know.
You gave much arguments for my report thx!!!
Jürgen
|
|
| | | | | | |
| Re: Arguments contra GMF and pro GEF [message #248817 is a reply to message #248607] |
Wed, 06 May 2009 09:12 |
| Eclipse User |
|
|
|
Jens v.P. schrieb:
> Frankly, I know GEF pretty well and I'm sometimes faster implementing
> the editor from scratch with GEF instead of using that not very
> user-friendly GMF generation tool. And GMF really adds lots of
> complexity. For example, I can create a basic editor with about 20
> classes, while the GMF generated code consists of 80 classes. OK, the
> GMF generated stuff is more powerful, but if you don't need all that
> functionality, it is only a burden. On the other hand I really like
> using GMF's notation model, because implementing this by yourself is not
> as easy as it sounds.
Well said! I would like to point out that the choice is between GEF and
GEF+EMF+GMF. It's sort of three times the complexity of GEF only. Of
course, also 3 (or more) times more powerful.
Our customers always ;-) want "nasty" features in the editors far beyond
the usual UML-like box-and-line diagrams. To implement these features,
you must master GEF. Master!
If it were possible to use only the higher-level GMF without touching
any GEF code, it would be great. But in real life I don't think this is
possible.
Frank.
--
Dr. Frank Gerhardt
Gerhardt Informatics Kft.
http://www.GerhardtInformatics.com
--
SENS-Expert http://www.SoftwareExperts.de
|
|
|
Goto Forum:
Current Time: Mon Apr 14 17:34:33 EDT 2025
Powered by FUDForum. Page generated in 0.03498 seconds |
Home