An addition: I have created https://bugs.eclipse.org/bugs/show_bug.cgi?id=440098 so we have a place for a more detailed discussion.
Cheers Alexander
Hi Miro,
I could take a first short glance and some (conceptual) questions already came to my mind, while I unfortunately did not have the time to look into all details yet:
- What exactly was the motivation of factoring our EdgeLayout into own interface? Does it make sense to haven an Edge without the properties contained therein? - What was the motivation of doing the same for ShapeLayout? It seems all GraphElements extend also this interface. Why is there then no "Shape" abstraction but only a ShapeLayout? - Why exactly do we need the PropertyMapping? It seems transient properties are already handled by a map. Why not use the same mechanism here? What is the notion of "persisting" them?
@Zoltán: Could you take a look into how we could realize the separation between EMF-unrelated interfaces and EMF-based implementation?
Cheers Alexander
Thanks Miro. I will probably have to for a detailed look tomorrow to give a first feedback.
I would like to do the discussion here or in a related bug (but not outside of the Eclipse infrastructure), so our community can participate.
Cheers Alexander Hi all,
I created an Ecore-based graph structure proposal in a GitHub repository:
http://github.com/franchi82/kgraph
Feel free to experiment with it. I suggest that discussion on this proposal should be continued using GitHub issues.
Regards Miro
On 09.07.2014, at 23:10, Alexander Nyßen <alexander.nyssen@xxxxxxxxx> wrote:
Regarding the question whether to use EMF or not, we decided that we (read: the KIELER project) need EMF in any case. We have two options: * specify the data structure directly in Ecore, or * create interfaces and an EMF-independent implementation in one plugin and an Ecore-based implementation in another plugin. Even if EMF is used, it is possible to use the data structure in Eclipse-independent applications by shipping the plugins org.eclipse.emf.common and org.eclipse.emf.ecore with it. This gives an overhead of about 1.6 MB.
I do not object to using EMF and I think that the overhead is something that we could well live with. Actually the approach you describe would facilitate the split of GEF4 Graph into interfaces and implementation, as I proposed earlier. I think from our viewpoint, the following would be desirable:
1) the generated interfaces should not make use of the EMF collection classes (i.e. use a plain List instead of an EList) and (if possible) should not extend EObject, so we could put them into a bundle without any EMF dependencies (I think this can be achieved by certain EMF genmodel options). 2) the implementation classes could be put into a separate bundle that depends on EMF. I do not think we would have to provide a non-EMF-based implementation in addition, at least I do not see a direct use case for this yet.
This way, the use case of writing adapters between GEF4 Graph interfaces and a custom model would remain pretty much lightweight (no EMF contracts to follow), while a transformation scenario would also be best supported (here, EMF seems to be advantageous).
It is possible to remove all EMF classes from the interface. The only thing required is having some javadoc tags defined for the interface, after that EMF can generate everything required. I have first-hand experience with this - if we can follow the (naming) conventions of EMF, it works really well. The most problematic point I see is providing a modifiable list for multivalued attributes - this requires specific list implementations that can send change notifications (at least if we want to make the graph model dynamic).
Would it be feasible that I send a proposal consisting of an Ecore model file, and you generate EMF-free interfaces + EMF-bound implementation out of it?
That would probably be useful (1) to concretize our discussions about the actual changes that would have to be applied to GEF4 Graph to match your requirements and (2) to confirm whether the intended approach of separating GEF4 Graph into a set of EMF-indenpendent interfaces and related EMF-based implementation is feasible. As such, I would welcome this procedure.
_______________________________________________ gef-dev mailing list gef-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/gef-dev
-- Dr. Alexander Nyßen Dipl.-Inform. Software-Engineer
Telefon: +49 (0) 231 / 98 60-210 Telefax: +49 (0) 231 / 98 60-211 Mobil: +49 (0) 151 / 17396743
http://www.itemis.de alexander.nyssen@xxxxxxxxx
itemis AG Am Brambusch 15-24 44536 Lünen
Rechtlicher Hinweis:
Amtsgericht Dortmund, HRB 20621
Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus
Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus
_______________________________________________ gef-dev mailing list gef-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/gef-dev
-- Dr. Alexander Nyßen Dipl.-Inform. Software-Engineer
Telefon: +49 (0) 231 / 98 60-210 Telefax: +49 (0) 231 / 98 60-211 Mobil: +49 (0) 151 / 17396743
http://www.itemis.de alexander.nyssen@xxxxxxxxx
itemis AG Am Brambusch 15-24 44536 Lünen
Rechtlicher Hinweis:
Amtsgericht Dortmund, HRB 20621
Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus
Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus
_______________________________________________ gef-dev mailing list gef-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/gef-dev
-- Dr. Alexander Nyßen Dipl.-Inform. Software-Engineer
Telefon: +49 (0) 231 / 98 60-210 Telefax: +49 (0) 231 / 98 60-211 Mobil: +49 (0) 151 / 17396743
http://www.itemis.de alexander.nyssen@xxxxxxxxx
itemis AG Am Brambusch 15-24 44536 Lünen
Rechtlicher Hinweis:
Amtsgericht Dortmund, HRB 20621
Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus
Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus
|