[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [henshin-dev] Common project, editors
|
Hi,
the approach I used to combine the editor was to keep the diagram
editor as-is and slightly modify the EMF-generated editor to display
the diagram editor in a tab, as outlined in this article:
http://www.eclipse.org/articles/article.php?file=Article-Integrating-EMF-GMF-Editors/index.html
However, I don't think this is the right solution for several reasons,
the most important being that it does not improve either editor.
Integrating the editors might be best done by a seperate project,
which might also be more extensible. Juno seems to offer nice features
for extensible editors which I want to look into.
However, during my implementation I noticed that for example the icons
should really not be in an editor project. They are not part of any
editor, they are just icons; projects not requiring editor
functionality but requiring the icons should not have to be dependent
on the editor. Thus, I suggest extracting the icons to a common
project. There might be even more common features in Henshin's code
base, especially as far as the editors are concerned. It could be
worth the effort to refactor the code to make the project dependencies
more logical.
I would start by introducing a "common" plugin and at least storing
the icons there. Only very little editing is needed to have the
existing editors and the statespace explorer use these icons. I don't
know how we handle Strings at the moment, but there might even be a
point in having all common Strings in the common project as well and
not separately in each project. Is there anything speaking against
introducing a common plugin that I might have overlooked?
In general, I would rather adjust the existing graphical editor so
that it can be used in a multi-view editor, rather than creating and
having to maintain a second version of it.
This is the overall idea. With the approach outlined in the article,
very little editing of the graphical editor was necessary. I think an
even better approach would be to let a separate plugin handle
integrating the editors, so no already-existing editor will have to
handle the editor integration. Thus, even less editing of the existing
editors will be necessary.
I will look into this.
Felix