redVoodo – a good idea to use eclipse databinding

Actually i am writing the UI controllers which are connecting the redVoodo UI model with the UI parts that are responsible to visualize the model. After a sleepless night i decided to refactor the whole controller code. The problem was that i had to implement tons of observing code which observes the UI model for a few nodes and causes the UI parts to reflect these changes immediately. Of course, this solutions would have worked really well, but i did not like the way how this solution works.

In this blog i am going to describe why i decided to use eclipse databinding and show some code.

The UI model

RedVoodo offers a functionality called scoped actions and menu items. See post redvoodo-scoped-actions-and-menu-items

Based on this feature actions and menu items are hidden if they are not in the scope of the active framework or sub application. For instance, an action called “delete Item” will only be visible in the “Item Subapplication” but will be hidden for the “Customer Supapplication”. These actions and menu items have “subapplication scope” which means, that they are only visible if a defined sub application is active. But there are also “framework scoped” actions and menu items. Their visibilty depends on the active framework like Sales, Inventory,…

If you want to write an application which tracks the currently active subapplication or framework, perhaps you have to write tons of code if the underlying UI model has a deep structure.

This class diagram shows a simplified version of the redVoodo UI model. The root element of the model is called YUiModel. It can contain exactly one YApplication which is an abstraction of the vaadin application. The YApplication contains many YFrameworks (like Sales, Inventory,…), but only one YFramework can be active at a time. Based on the active framework, different sub applications are shown. So each framework has its own set of YSubapplications. For instance, the framework sales could contain sub applications like Customers, SalesCampains,…

The application, each framework and each sub application can contain their own set of actions. Depending on the active framework and the active sub application, different actions should be visible at the UI.

This image shows what i am talking about:

If the sales framework or a different sub application would be selected, completely different actions and menu items would be shown.

The model shown above is an EMF model. But since redVoodo should be a very extendable framework, using EMF is the default implementation. The core of redVoodo does not have any dependency to EMF. Instead it has a dependency to model controllers. These controllers are called edit parts. The UI parts like the “framework switcher” or the “sub application tree” are using these edit parts to visualize the model but do not have a dependency to the underlying model. So everybody can easily change the default implementation and provide edit parts that are based on a JPA implementation or edit parts that are even hardcoded.

The problem

Yesterday i started to write a lot of code to observe the ui model. I had to fetch the RootModelEditPart which represents YUiModel.

  • I registered a listener at the RootModelEditPart which will be notified if the active application changes.
  • Then i implemented the same issue for the active application and added a listener to the active application which becomes notified if the active framework changes.
  • Then i added a listener to the active framework which becomes notified if the active subapplication changes.
  • Then i added a listener that becomes notified if actions are added or removed.
  • Then i started to handle many different constellations based on parts that become active and deactive.
    • Remove listener from the lower containment structure
    • Switch the parent
    • Add the listener again to the lower contaiment structure
  • Then i detected that each UI part has a different behaviour to the observables. The SubApplicationTabBar has to observe the OpenSupApplications-reference from YFramework too.
  • Then, at 10 p.m. i thought -> Hmmmmmmmmmm, what a boring job!

After a sleepless night, i took all the controller implementations and put it to trash since eclipse databinding can do all that stuff for me. I can heavily reduce the amount of required code and safe a lot of time.

The (really easy) solution

// 1. define a nested property
// 1. define a nested property
String nestedProperties =
 "application.activeFramework.activeSubapplication.actions";

// 2. create the observable model value
IObservableValue modelOV = BeansObservables.observeDetailValue(
	new WritableValue(rootModel, IRootEditPart.class),
	nestedProperties, ISubapplicationEditPart.class);

// 3. create the observable target value
IObservableValue targetOV = PojoObservables.observeValue(
	ActionbarPart.this, "subapplicationActions");

// 4. bind model to target
subapplicationActionsBinding = dbContext.bindValue(targetOV,
  modelOV, new UpdateValueStrategy(
	UpdateValueStrategy.POLICY_NEVER),
  new UpdateValueStrategy(UpdateValueStrategy.POLICY_UPDATE)
	.setConverter(new NotNullConverter()));

1. define a nested property

This nested property will be splitted by the “.” and the reference path starting at the IRootEditPart will be followed for each property.

// "application.activeFramework.activeSubapplication.actions"
// "application.activeFramework.activeSubapplication.actions"
// can be visualized as:
rootModel
	.getApplication()
	.getActiveFramework()
	.getActiveSubapplication()
	.getActions()

The property “actions” inside the “activeSubapplication” will be observed. Every time it changes – nevertheless why it changes (due to a change of active framework or something) – we are becoming notified.

So we do not have to implement that boring listener hierarchy as described under “the problem”.

2. create the observable model value

Creates an IObservableValue which represents the “actions” property inside the “activeSubapplication” inside the “activeFramework” inside the “application”

3. create the observable target value

Addresses the property “subapplicationActions” of this instance (ActionbarPart.this). Every time the “actions” from “activeSubapplication” changes, the setter this#setSubapplicationActions(IActionEditPart editPart) should be invoked.

4. bind model to target

Therefore the DatabindingContext is used to bind the ObservableValues (model and target) to each other.

And here you can see the implementation of the setSubapplicationActions-method. It stores the subapplicationActions and puts it to the UI.

/**
 * Sets the list of subapplication actions.

 * Called by databinding.
 *
 * @param subapplicationActions
 *            the subapplicationActions to set
 */
public void setSubapplicationActions(
		List subapplicationActions) {
	internalSetSubapplicationActions(subapplicationActions);

	toUI_subapplications();
}

That’s all i had to write to observe a nested property inside my model tree.

I hope you can see the big advantage of eclipse databinding too and hope you give it a try.

Additional informations

Eclipse databinding
redVoodo.org
vaadin.com

Advertisements

Tags: , , , , ,

13 Responses to “redVoodo – a good idea to use eclipse databinding”

  1. smcela Says:

    Very interesting idea. I will certainly give it some exploring. I am a fan too of integrating some very useful Eclipse technologies into the dynamic Vaadin apps possible with OSGi.

    Recently I used EclipseLink to persist or retrieve some model on the application. http://smcela.wordpress.com/2011/06/28/osgi-jp/

    This may be useful for redVaadin when it comes to persisting model data.

    Keep up the great work.

    smc

  2. Florian Pirchner Says:

    Hi,
    i could take a very short look at the sourcecode of your implementation. Great!

    For sure if we are going to persist model by JPA i will explore it in detail.

    Thanks a lot for your comment.

    Florian

  3. Sopot Çela Says:

    In fact the OSGi nature of eclipse itself makes it easy to integrate with other OSGi technologies.

    It would be great if you could put the actual (even if not complete) code of redVoodo on a git repository so it is easy to give it a try and contribute.

  4. Florian Pirchner Says:

    Yes, we are going to provide the source code in about 2 weeks.

    Then also an advanced example should be available. And who knows -> Maybe you are interested in providing a JPA based model persistence… 😉

  5. Sopot Çela Says:

    That would be great 😉

  6. strony internetowe gdańsk Says:

    Thanks very interesting blog!

  7. fernandosoler Says:

    Hi, Is still possible to check the UI data model of this project? Thanks

  8. Florian Pirchner Says:

    Can you please send me your email address to florian.pirchner@gmail.com.

    Then i will send you some information.

    Added you to bitbucket repo.

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


%d bloggers like this: