| Re: [elk-dev] ELK Refactoring |
Hi there, good work, I've left my comments on GitHub. All in all, I have to say I'm having a hard time really getting to grips with all the changes just from the pull request. I guess I'll have to see how everything works, so I might suggest more changes further down the road. However, we can merge the request as far as I'm concerned. Cheers, Christoph Daniel On 20/01/16 17:06, Miro Spönemann wrote: > Hi elk lovers, > > it’s review time again: > > https://github.com/eclipse/elk/pull/4 > > With this change people should be able to customize quite a lot of stuff > already: > DiagramLayoutEngine > IDiagramLayoutConnector > ILayoutConfigurationStore > LayoutConfigurationManager > IGraphLayoutEngine > LayoutPropertySource > and we could easily add more like this in the future, especially > regarding the UI. > > Maybe the most important point to understand about the change is in > the invokeLayout method of DiagramLayoutEngine line 271. Here we have a > transition from static code to non-static code. If that’s too strange, > we could move the non-static code to a new class. > > Miro > > >> On 14.01.2016, at 12:49, Christoph Daniel Schulze >> <cds@xxxxxxxxxxxxxxxxxxxxxx <mailto:cds@xxxxxxxxxxxxxxxxxxxxxx>> wrote: >> >>> Currently you can only adapt IDiagramLayoutManager >>> and ILayoutConfigurationStore, where the former acts as a provider for >>> the latter. If we later decide to add more customization points we >>> cannot use the same provider concept because that would break existing >>> implementations of IDiagramLayoutManager, so we would need yet another >>> extension point. The benefit of DI is that all customized classes are >>> registered through a Guice Module, so >>> 1. we have a consistent concept for all customization points, >>> 2. it’s no problem to add more customization points later. >>> >>> My expectation is that by making customization easier the long-term >>> effect will be more flexibility and thus more users, since a tool is >>> more likely to be discarded if it cannot be adapted for the needs of an >>> application. >> >> Your second point seems to me to be a good reason. > > > > > _______________________________________________ > 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 >
Attachment:
signature.asc
Description: OpenPGP digital signature