Skip to main content

Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » GEF » Why MVC and MVC.FX bundles have been merged?
Why MVC and MVC.FX bundles have been merged? [message #1751692] Thu, 12 January 2017 15:28 Go to next message
Krisztian Koncz is currently offline Krisztian KonczFriend
Messages: 31
Registered: September 2014
Location: Budapest

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 15:30]

Report message to a moderator

Re: Why MVC and MVC.FX bundles have been merged? [message #1751744 is a reply to message #1751692] Fri, 13 January 2017 11:57 Go to previous message
Matthias Wienand is currently offline Matthias WienandFriend
Messages: 230
Registered: March 2015
Senior Member
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.


Best regards,
Previous Topic:ClassNotFoundException: javafx.embed.swt.FXCanvas cannot be found by org.eclipse.gef4.mvc.fx.ui
Next Topic:ZEST as Editor rather than a View
Goto Forum:

Current Time: Fri May 24 01:17:59 GMT 2024

Powered by FUDForum. Page generated in 0.03743 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top