[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [elk-dev] ELK Refactoring
|
Hi all,
For what it's worth, I've built a small ELK connector for Papyrus editors (It required tweaking the ELK GMF Connector a little bit to unwrap DiagramEditors from the Papyrus MultiDiagramEditor)
It's probably not complete as I've not overridden all the "problematic" ELK/GMF classes (Problematic from the Papyrus integration point of view), but it works for the cases I've tested. So if you're looking for examples, that's maybe one way to do it
Regards,
Camille
-----Message d'origine-----
De : elk-dev-bounces@xxxxxxxxxxx [mailto:elk-dev-bounces@xxxxxxxxxxx] De la part de Christoph Daniel Schulze
Envoyé : jeudi 7 janvier 2016 12:31
À : elk-dev@xxxxxxxxxxx
Objet : Re: [elk-dev] ELK Refactoring
Hi Miro (and everyone)!
On 23/12/15 15:50, Miro Spönemann wrote:
> Yeehaa! Our first pull request!
*cheering noises from the audience*
> - 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...
> - I would vote for changing the CheckStyle configuration to be less
> strict. In particular:
> - All header lines are marked with warnings. That check should be
> either corrected or removed.
I vote for correcting it. File header comments are necessary.
> - Don't insist on requiring any JavaDoc tags, especially @author. I
> would also vote for not requiring @param and @return since that leads to
> many stupid tags that don't add any information, e.g. I found
> /**
> * Returns the type.
> *
> * @return the type
> */
> /**
> * Sets the name.
> *
> * @param thename the name to set
> */
Yeah, personally I don't care for author tags too much. Not requiring
@param and @return tags as alright with me, provided that people don't
abuse that freedom... ;)
> - Increase the maximal line length (e.g. to 120).
Fine with me.
> - I'm not sure whether it really helps to require all method
> parameters to be final.
I guess that's one of the things people can discuss endlessly, but
doesn't make that much of a difference at the end of the day. I don't
know how much it helps, but I don't think it hurts. It at least forces
me to think about what I'm doing if I try to change a parameter's value.
> - 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.
> - 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.
Cheers,
Christoph Daniel
