| Syncing different Parts together [message #1665535] |
Wed, 11 March 2015 09:20  |
|
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 #1668598 is a reply to message #1665535] |
Thu, 12 March 2015 15:15  |
Eclipse User |
|
|
|
Hi Piero.
Quick thoughts.
To me, databinding, events, and DI are just techniques with strengths and weaknesses.
Although you could use DI to broadcast model changes (e.g., by changing the object for a particular key), I'm a bit wary of using a context to represent model state. (As compared to making particular bits of your model state available through a context, which I think is fine.)
Events are great when you want to avoid a subscription process. Events are no more error-prone than observer broadcasts. The E4 UI model is entirely based on EMF events.
Brian.
|
|
|
| Re: Syncing different Parts together [message #1679162 is a reply to message #1668598] |
Mon, 16 March 2015 13:53 |
|
Dear Brian,
thanks very much for your comments.
I am not really clear about your statement: "I'm a bit wary of using a context to represent model state. (As compared to making particular bits of your model state available through a context, [...])".
Is it possible to briefly elaborate that..? 
Thanks in advance.
-Piero
|
|
|
| Re: Syncing different Parts together [message #1679427 is a reply to message #1679162] |
Mon, 16 March 2015 16: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.01868 seconds
] 
Search
Help
Register
Login
Home
