Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » JFace » Syncing different Parts together
Syncing different Parts together [message #1665535] Wed, 11 March 2015 09:20 Go to next message
Piero Campalani is currently offline Piero CampalaniFriend
Messages: 112
Registered: January 2015
Senior Member

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 Go to previous messageGo to next message
Brian de Alwis is currently offline Brian de AlwisFriend
Messages: 788
Registered: January 2012
Senior Member

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.


Eclipse Platform committer. Ask me about Eclipse support, training, and consulting.
Re: Syncing different Parts together [message #1679162 is a reply to message #1668598] Mon, 16 March 2015 13:53 Go to previous messageGo to next message
Piero Campalani is currently offline Piero CampalaniFriend
Messages: 112
Registered: January 2015
Senior Member

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..? Smile

Thanks in advance.
-Piero
Re: Syncing different Parts together [message #1679427 is a reply to message #1679162] Mon, 16 March 2015 16:08 Go to previous message
Brian de Alwis is currently offline Brian de AlwisFriend
Messages: 788
Registered: January 2012
Senior Member

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:

  1. 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.

  2. 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.


Eclipse Platform committer. Ask me about Eclipse support, training, and consulting.
Previous Topic:Data binding to an EMF model via feature path
Next Topic:TreeViewer & Columns number
Goto Forum:
  


Current Time: Thu Nov 15 23:03:02 GMT 2018

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

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

Back to the top