| 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
Attachment:
signature.asc
Description: OpenPGP digital signature