| Re: [elk-dev] ELK Refactoring |
Hi,
thanks Miro.
On Dec 23, 2015 3:51 PM, "Miro Spönemann" <miro.spoenemann@xxxxxxxxx> wrote:
>
> Merry Christmas!
>
> I finally found some time to do the refactoring of the layout configuration approach. I think now it’s all a lot easier to understand, but we lost support for configuration via extension point and via preference page. The changes can be reviewed here:
>
> https://github.com/eclipse/elk/pull/1
>
> Yeehaa! Our first pull request!
> Feel free to leave some comments there (they can also be inlined in the code). If there are no objections, I would merge the PR after my vacation, then of course you can further clean up the code and fix all the bugs I introduced ;-)
Ok!
>
> The rest of this email is about general observations and thoughts.
>
> — 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.
>
> — 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.
What do you mean by headers?
> - 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
> */
Agree.
> - Increase the maximal line length (e.g. to 120).
Not sure, I like having two editors side by side. Still, I wouldn't complain if you change it.
> - I’m not sure whether it really helps to require all method parameters to be final.
>
> — 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.
Sounds reasonable. If we find time, we should do it.
>
> — 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.
We have to check if gwt supports any of this. Otherwise we would have to drop klayjs, which I think we don't want to, right?
>
> Happy new year
> Miro
>
> _______________________________________________
> elk-dev mailing list
> elk-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/elk-dev
>