[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [elk-dev] ELK Refactoring
|
| Hi!
— I fetched ELK via Oomph. I didn’t find any example GMF editor in that
installation, so I tested only the Graphiti integration, but not the GMF
integration.
Good to hear that the Oomph setup works for you. There's still a few details to be cleaned up there. For the EclipseCon and Demo Camp presentations, I used a mindmap editor that I built following one of the GMF tutorials. What we'd ultimately want is probably something a bit more complex to test things with. The old KEG editor would actually be quite nice for that, but I didn't want to bother changing all the package names just to get it into ELK…
Could you share the projects of the mindmap editor? Maybe not in the repository, a zip download would be enough for me.
— We still have the problem that meta data on layout options have to be
duplicated (XML + Java). An idea for improving the situation is to
create a DSL to describe the complete meta data of algorithms and
options and to generate Java code out of that. That would give us a very
comfortable interface to manage that meta data consistently. The DSL
editor itself would not be part of the ELK runtime feature, but could be
shipped with an additional SDK feature. However, this approach would
require the ELK DSK feature to be installed in our development Eclipse
instance, so it should be included in the Oomph setup. The same approach
is also employed by Xtext.
That doesn't sound bad. Since documentation has always been a huge problem as well, I'd like to see that integrated into the concept as well.
Ok, I’ll make a proposal after PR #1 has been merged.
— We should think about good ways for ELK users to customize the
behavior of the whole infrastructure. We could use Guice dependency
injection for that, which makes it a lot easier to replace default
implementations by your own custom code.
How much is there to be customized, really? I guess I would like to see a concrete set of proposals to think about.
Potential places for customization: — IDiagramLayoutManager — ILayoutConfigurationStore — LayoutConfigurationManager — IGraphLayoutEngine — Some parts of DiagramLayoutEngine — LayoutPropertySource
My idea: instead of registering an IDiagramLayoutManager directly through the extension point, you register some Setup class that is able to create a Guice Injector. That one is cached in the LayoutManagersService and used to create instances of the classes mentioned above.
Miro |
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
