Interesting new feature in EMF-Databinding


I’ve invested sometime into EMF-Databinding to add a new quite interesting feature i guess. Currently we have to problem that if your nested path crosses a multi-valued feature (=java.util.List) at some point the only solution today is to create a volatile transient feature which observes your EList and fire change events but this really clutters your Ecore-Model.

Let’s take a look at an example model

you’d like to present in an UI like this:

Until EMF 2.7M7 you’d have to modify your EMF-model like this:

So that you could e.g. write something like this to get access to the private address’ city property:

import static at.bestsolution.e4.addressbook.model.addressbook.AddressbookPackage.Literals.*;

// ...

IEMFValueProperty mProp = EMFProperties.value(FeaturePath.fromList(PERSON__PRIVATE_ADDRESS,ADDRESS__CITY));

// or in longer builder type syntax
IEMFValueProperty mProp = EMFProperties.value(PERSON__PRIVATE_ADDRESS).value(ADDRESS__CITY);

With the new feature I’ve added to IEMFListProperty#value(ListElementAccess) one now does not have to create those volatile transient features any more but can write the long form like this:

IEMFValueProperty mProp = EMFProperties.list(PERSON__ADDRESSES).value(
  new ElementAccessImpl(AddressType.PRIVATE)
);

// ...
private class ElementAccessImpl extends ListElementAccess<Address> {
 private AddressType type;

 public ElementAccessImpl(AddressType type) {
  this.type = type;
 }

 @Override
 public int getReadValueIndex(List<Address> list) {
  int i = 0;
  for (Address o : list) {
   if (o.getType() == type) {
    return i;
   }
   i++;
  }
  return -1;
 }

 @Override
 public int getWriteValueIndex(List<Address> list) {
  int i = 0;
  for (Address o : list) {
   if (o.getType() == type) {
    return i;
   }
   i++;
  }
  return -1;
 }
}

I’d like to note that this feature is an experimental one and we don’t guarantee to break it e.g. by pushing it upstream to Eclipse Databinding but you are free to give it a try and report usefulness, problems, like, dislike, … .

BTW did you notice that the screenshot from the above application was taken from a Swing-Application? How can that be? Isn’t Eclipse Databinding (and because of that EMF Databinding ) only useful within SWT driven apps (e.g. Eclipse RCP ones)?

Without saying too much: No – because many core Eclipse technologies OSGi, Databinding, EMF, Eclipse 4 Application Platform to name some can be used with any UI-Technology

This entry was posted in EMF. Bookmark the permalink.

7 Responses to Interesting new feature in EMF-Databinding

  1. Eike Stepper says:

    Hi Tom,

    I guess when you’re talking about “volatile” features you really mean “transient” features. I think it’s pretty important to make this distinction, especially to new EMF users, because typically presistence (resource) implementations do not check for volatile but for transient features.

    Cheers
    /Eike

    • Tom Schindl says:

      Thanks, you are right I forgot to set transient in the 2nd in one of the paragraphs – it’s fixed now

  2. Pingback: Taking JavaFX for a spin | Tomsondev Blog

  3. Mark Rowe says:

    Hi Tom,

    Thank you for your articles. Is the address book project pictured above (or better a SWT/JFace version!!) available for download somewhere?

    Thanks, Mark

  4. Hy Tom, thanks for this blog entry! Could you possibly give a short info on the properties of the respective EReferences? That is, how does the EReference privateAddress select its resp. entry in the addresses list? I am currently facing such a problem with the usage of a Feature$Map and try to get the corresponding FeaturePath to work!

    Thanks a lot!
    marco

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.