| Syncing different Parts together [message #1665535] |
Wed, 11 March 2015 05:20  |
Eclipse User |
|
|
|
Dear experts,
this is a more of a high-level design question.
I am building an E4 RCP application here, where I have a central GIS map and 1+ parts (eg JFace viewers) which I want to be tightly synchronized altogether.
I would like to ask to you all what would be your personal approach to this task, implementation-wise, keeping into account that performance counts here due to the heavy burden of map updates/editing.
I have the feeling that using a sort of "star-shaped" data-binding (1 observable model with N GUI elements on the other end) is the most robust method here, while playing with sending/posting events + DI is somewhat more loosely-coupled and more prone to errors.
How would you tackle this architecture?
How does Eclipse itself work it out?
Thanks for any help,
-Piero
|
|
|
|
|
| Re: Syncing different Parts together [message #1679427 is a reply to message #1679162] |
Mon, 16 March 2015 12:08  |
| Eclipse User |
|
|
|
I mean using the IEclipseContext as a representational mechanism as compared to having an explicit model object. For example, consider a situation where you have editors for manipulating locations with attributes 'name', 'address', 'hours' , and 'keywords'. You could (and I'm recommending) creating a model object for Location with fields. But you also eschew the actual model object entirely and push the location attributes directly into the editor context as keys: changing the name, for example, would automatically re-inject any locations that used the name.
This context-as-representation seems quite appealing -- conceptually it seems little different from using EMF or POJOs to represent your model objects, but you're able to do away with listener frameworks, etc. The difference comes from how the objects are hooked to for updates. This matters as an object cannot be injected from two different contexts. By using a context as representation, your model is now tied to the context and the hierarchy in which that context is situated. There are two approaches that I've seen:
- You embed your 'object' into the context of some E4 UI object (e.g., you push it into the MPart for the editor's context), or you create a child context parented from the editor's context. But these objects are a bit difficult to access elsewhere (have to be injected from a particular editor's context), your model becomes tightly coupled to the E4 UI model (you bake in knowledge of how to locate objects into your code), and you also run the risk of key collision (e.g., "name" will almost certainly collide elsewhere), so you'll have unwieldy key names. And your model is now tightly coupled to the E4 UI model + context hierarchy; headless usage is a bit difficult.
- You create your own independent context hierarchy. But you'll likely end up creating dyads of two tightly-coupled objects that are injected from different contexts. Which is little different from having a separate model facade object.
Or there's a third, hybrid, approach: separate model objects, but whose changes are propagated into the context.
Brian.
|
|
|
Powered by
FUDForum. Page generated in 0.19797 seconds
Home