Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: AW: [jwt-dev] Feedback on GMF analysis 
Hi all,
First of all, I really hate the GMF tools. While I can definitely see value in quickly generating a DSL editor, I found that the metamodel is badly documented and once you divert from the tutorial type paths, it becomes really hard to understand why things go wrong when they do. Also the proposed path of generating an application and then tweaking the generated code is basically flawed IMO. As a last point, I found that the editors generated by the tools didn't fully exploit the extension points and API provided by the GMF runtime frameworks. The generated code was a lot more bloated than I thought it needed to be. That said, the GMF runtime frameworks provide a huge amount of convenience. With huge I really mean HUGE. Almost two years ago I developed a small editor for directed graphs using the GMF runtime frameworks (that is without using the tools) and it involved almost no coding. I also know that a lot of the tooling out there such as the Rational tools use the GMF runtime frameworks extensively. There are a lot of widgets, tools, tricks, algorithms and other stuff readily implemented and ready to be picked and included in the editors you build on top of it. The major drawbacks that have prevented me from using the GMF runtime frameworks directly are twofold: - a framework with huge possibilities and with very basic documentation implies a very steep learning curve which I never managed to end completely - I never found a way to easily tweak the serialization of the editor, but that could be because of my ignorance wrt EMF. I differ on the topic of extensibility of a GMF based editor. I found they are quite extensible but not if they are generated. You really have to contribute to the extension points provided by the runtime frameworks (which is not done systematically by the GMF tools apparently). 

My 2 cents,
Koen
Op 13-mrt-09, om 13:51 heeft Christian Saad het volgende geschreven:


Hi Pierre,
thanks for your feedback. It provides some valuable insight into the current development status of the GMF project. Indeed, it seems that as the GMF environment becomes more stable its popularity has increased quite a bit but as you have pointed out, it is probably still very difficult for someone who is completely new to the EMF/GEF world to create a graphical editor from 
scratch.
The separation of model and view data is a very important feature in GMF and we're currently working on doing this in JWT, also separating the meta model 
completely from the editor.

It would be interesting to do a comparison between features that are
automatically provided by GMF with JWT's features. As mentioned, I'm not quite up-to-date with GMF but considering the work done in the last I hope we're doing quite well. But you are right, we need to make sure we have the 
features that convince people to use JWT instead of creating their own
editor. A swimlane view would be a nice example for as far as I know, this 
doesn't come with GMF ;)

Regards,
Chris



-----Ursprüngliche Nachricht-----
Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx]
Im Auftrag von Pierre Vigneras
Gesendet: Donnerstag, 12. März 2009 16:05
An: jwt-dev@xxxxxxxxxxx
Betreff: [jwt-dev] Feedback on GMF analysis

Dear all,

I would like to share my "personnal" vision on our study of GMF
technology and
its relevance in the case of the JWT project (and its extension).

My opinion is the following (to be short):
- EMF is quite mature and is fine to be used. But it is definitely the 
core of
a GMF designer. In the case of JWT, the fact that the meta-model is
UML-AD
based, may lead to some problems for the implementation of a BPMN
extension
(as we have seen with the And/Xor stuff).
- GMF Runtime is also quite mature now. The problem I personnaly found 
is with
the GMF tooling which is quite buggy and not as user-friendly as I
would like
it to be. GMF is quite complex. The learning curve seems to be quite
huge (as
it is based on GEF, which itself is based on JFace/SWT and Eclipse/ PDE, 
Eclipse/JDT, and so on ;-)).
- GMF is based on models extensively. In particular, it imposes a clear 
separation between the business model (BPMN or UML-AD) and its
graphical
representation. This leads to a better overall design. For example,
location
of elements is stored separetely from elements themselves. We have seen 
in
JWT that we are facing similar problems when considering swimlanes.

- GMF makes generic/extensible designers irrelevant somewhat since it
has been
specifically design to ease the making of specific designers. I mean, 
if you
need a new designer, GMF makes it "easy" to create a new specific one
from
scratch. Therefore making a GMF designer extensible/generic may sound
strange
in this context.
- GMF provides from scratch many cool stuff (ArrangeAll, Print Preview, 
Snap
to Grid, Snap to Object, Cut/Paste, Undo, and so on). Those stuff must 
be
provided by JWT, at least.


Conclusion: IMHO, there is no equivalent AFAIK, of GMF/Eclipse.
Therefore,
whenever you need a designer (such as JWT), your single option is
making one
from scratch (or using some API that may help a bit). In that case, you 
are
free to use the technology you want, and in particular, web ones. But
unless
you need also an IDE (as it is the case with the Bonita designer,
designing a
Business Process also involve coding in Java), Eclipse is a must. In
that
case, the trend is definitely towards GMF-based specific designers. I
personnaly find that GMF has a lot of weak points (in particular the
tooling
which is both buggy and undocumented) but there is no equivalent
currently
AFAIK.
Finally, considering JWT, since its purpose is to provide an extensible designer, it is quite fine to make it using GEF only (and not GMF). On 
the
other side, JWT will have to provide much more features in order to get 
a
benefit extending it instead of creating an ad-hoc GMF-based designer 
from
scratch.

Regards.
--
Pierre Vignéras
Bull, Architect of an Open World TM
*BPM Team*, Bull R&D
1, rue de Provence
38130 Echirolles (France)
Direct Line: +33-4-76-29-74-06

*Orchestra*, The BPEL open source project: http://orchestra.ow2.org
*Bonita*, The XPDL open source project: http://bonita.ow2.org
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev



_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev

Back to the top