[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [elk-dev] ELK Refactoring
|
Hi elk lovers,
it’s review time again:
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
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.
|
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
