| Why MVC and MVC.FX bundles have been merged? [message #1751692] |
Thu, 12 January 2017 10:28  |
Eclipse User |
|
|
|
In the last few days I thought about to use the new GEF implementation with other rendering technology (openGL). I noticed that the MVC and and MVC.FX bundles were merged in the last half year. Unfortunately the JavaFX unrelated abstractions are gone with this change so it is impossible to use GEF4 MVC concepts with other rendering technology.
[Updated on: Thu, 12 January 2017 10:30] by Moderator |
|
|
| Re: Why MVC and MVC.FX bundles have been merged? [message #1751744 is a reply to message #1751692] |
Fri, 13 January 2017 06:57  |
| Eclipse User |
|
|
|
Hi Krisztian,
as outlined in the corresponding Bugzilla ticket #496248 [1], the separation of generic and JavaFX-specific framework abstractions was not considered beneficial, because of inconveniences in the client code: a visual root type parameter was needed (thus TypeToken had to be used often to safely query adapters with type parameters: getAdapter(new TypeToken<SelectionModel<Node>>() {}) => getAdapter(SelectionModel.class)), many type casts were needed (in order to access JavaFX-specific aspects, e.g. the viewer's canvas: ((FXViewer) getViewer()).getInfiniteCanvas() => getViewer().getCanvas()), and overcomplicated policy and behavior implementations were needed (separated into generic aspects and JavaFX-specific aspects).
So, the bottom-line criterion here is: does a division of the framework into visualization-agnostic and visualization-specific parts result in a benefit when developing an application? We found that the separation does not make so much sense, because it complicates the framework code as well as the client code. The client code does need access to concrete, visualization-specific parts most of the time. Therefore, we do not plan to support multiple rich client rendering technologies. Concerning web technologies (something that is often asked for), porting the underlying concepts to JavaScript (or TypeScript) seems to be a more appropriate approach than trying to target that with the current code base.
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=496248
Best regards,
Matthias
|
|
|
Powered by
FUDForum. Page generated in 0.07560 seconds
Home