JFace’s Viewers Usage Thoughts


Thanks to JFace viewers I can easily present anyone of my “model” inside an Eclipse view.

After several usages of this technology I am still sometime wondering how should I use it. Here is my dilemma:

Lets say we want to display a “model” (by model I mean here some Java POJOs representing application data) as a tree. Tree concepts are Children, Parent and Leaf. Of course these concepts must exist somewhere in my data model to present this model as a tree.

From here, depending on the relation between my data model and the tree concept, two solutions come in my mind (I am maybe missing something and that’s why I am blogging on the subject, so let me know about all your ideas, experiences …)

First solution: we perform ALL the  “model to tree” mapping in the content provider (Note that this IS the content provider purpose)

Direct mapping from model to tree in ContentProvider

This solution works perfectly when the data model IS a tree. I.e children, parent and leaf exists as it in the model. The data model of the first JFace TreeViewer Snippet is a good example of such a model.

Unfortunately, in real situations where we need to present data as trees, we must sometimes “Compute” the tree from the data. In such situations the ContentProvider implementation can quickly increase in terms of complexity and thus in terms of readability and maintainability.

Here’s come the second solution:

Undirect mapping of model to treeIn this solution, we first compute a “tree model” of the original data model. Then the ContentProvider implementation becomes really easy, since (as in the previously mentioned snippet) we directly return model’s children, parent and leaf to the viewer. In this case we created an intermediate model: “the view model

As I said previously, which solution I choose really depends on the context and mainly on the “Cost” and “Complexity” of the computation required to convert the model into a tree.

I will be interested in community feedback regarding this subject. How do you convert your data models to be presented in JFace viewers ??

Advertisements

5 thoughts on “JFace’s Viewers Usage Thoughts

  1. Thinking about the static structure of your tree is only the first – and easiest – step. It gets much more complicated as soon as you add dynamics, in the sense that your tree’s items, and its shape, change over time. (Calling viewer.refresh() doesn’t scale.)

    My recommendation would be to use parts of the data binding framework – have a look at ViewerSupport.bind (and its implementation, if your use case is covered by the simple helper API). Here’s a snippet that shows how you can use it: http://tinyurl.com/yefrj97

    The basic idea here is that a tree is composed of a number of observable lists, one for each parent node, containing the child nodes. If you can provide a factory that creates an observable list for a given parent node, or returns null if the given node is a leaf, then that’s all we need for the content side of a dynamic tree. If there is any computation involved, you can worry about that computation at the level of “how do I compute the observable list of children for a given parent node”.

    (An observable list is a java.util.List with additional methods for adding and removing listeners. It will fire events as elements are being added or removed. One simple implementation is WritableList.)

  2. It really depends. One problem with building a view model is that you have to be careful about what objects you return to the viewer. If there are any other views in the workbench that respond to selections that are related to your original model, then making a simple view model just won’t work.

    When I’m faced with that situation, I will sometimes create an internal view model that is contained inside the content provider which keeps a map to the original POJOs so that they can be returned by “getChildren” etc.. The internal view model is built on demand and stored with the content provider. You can clear it when the provider is disposed. This solution only works when there is a 1:1 relationship between content provider and viewer, though–which is the way that you really should do it.

    The data binding may work as well. It could be a good alternate solution. I’ve never really worked with data binding myself.

  3. Sounds like a job for GEF! In fact you’ve described one of the best use cases. I think that one way to think about GEF edit parts is precisely as you say — a “view model”. And an overlooked aspect of GEF is that it can be useful without any 2d content at all — just use the tree model. Sound like overkill? Perhaps, but if you think your usage is likely to grow to become more complex you’ll be ready — and GEF implementation really isn’t that much more complex than TreeProviders.

    p.s. it’s really nice when people post general issues like this as it gives us a chance to step back a bit and thing about high level usages.

  4. Hi, thanks to all for your positive and constructive feedbacks !!!

    I’ll investigate all directions you mentioned in order to consolidate my JFace and Gef knowledge.

    Thanks again
    Manu

  5. In addition to great ideas of other folks: you can use AOP (aspect oriented programming) to mixin tree related stuff on original model object

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s