|Re: Syncing different Parts together [message #1679427 is a reply to message #1679162]
||Mon, 16 March 2015 16:08
| Brian de Alwis
Registered: January 2012
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.
Eclipse Platform committer. Ask me about Eclipse support, training, and consulting.
Powered by FUDForum
. Page generated in 0.01695 seconds