Home » Eclipse Projects » GEF » Arguments contra GMF and pro GEF
| Arguments contra GMF and pro GEF [message #248530] |
Wed, 22 April 2009 15: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 10:12  |
|
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 12: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 #248638 is a reply to message #248618] |
Sat, 25 April 2009 07:47 |
| Eclipse User |
|
|
|
Originally posted by: cayla_sha.gmx.net
Jürgen Scheffler schrieb:
> 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
This is a good article, that describes the connection between GMF, EMF
und GEF:
http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclips e.gmf.doc/prog-guide/runtime/Developer%20Guide%20to%20Diagra m%20Runtime.html
If you look at the tree on the left side you could probably find also
more information about GEF.
|
|
|
| Re: Arguments contra GMF and pro GEF [message #248643 is a reply to message #248596] |
Sat, 25 April 2009 15:15 |
| Eclipse User |
|
|
|
Originally posted by: alamothe.ptt.yu
GMF is built on top of GEF. It is up to you to separate business and view
model if you need to. In the EDiagram example the separation is very clear.
GMF does this automatically, provided that its view model is good enough for
your editor.
exquisitus wrote:
> Considering models, GMF is based on EMF which eases DSL building,
> contrarly to GEF. Second, GEF doesn't make a clear separation between
> model and representation. With GMF, information about display is
> serialized elsewhere than the model. And most importantly, GMF
> generates a lot of code allowing you to focus only on customizing
> your editor. So there are a lot of advantages using GMF.
>
> Regards.
|
|
| | | |
| Re: Arguments contra GMF and pro GEF [message #248719 is a reply to message #248672] |
Tue, 28 April 2009 07:23 |
| Eclipse User |
|
|
|
Originally posted by: juergen.scheffler.gmx.de
exquisitus schrieb:
> I know. It was just to show that you can use GMF to get the same result
> then GEF without having to develop a bunch of code. Actually, I would
> use GEF only if my models were not EMF based.
>
> Jürgen Scheffler a écrit :
>> I didnt put it in question.
My arguments for GEF were
1. learing and understanding the sequence flow.
2. building "fancy" things into the Editor and RCP (we have real nasty
things ;))
|
|
|
| Re: Arguments contra GMF and pro GEF [message #248817 is a reply to message #248607] |
Wed, 06 May 2009 13:12 |
 Frank Gerhardt
Messages: 81
Registered: July 2009 |
Member |
|
|
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: Fri Apr 26 21:42:16 GMT 2024
Powered by FUDForum. Page generated in 0.03600 seconds |
] 
Search
Help
Register
Login
Home
