new Container for EObjects

Hi,

I’d like to write a container which supports the native reflective API from EClasses (EclipseModelingFramework).
It should work very similar to the BeanItemContainer but should avoid the use of java reflection.

Since EMF offers a really flexible type system the use of EFeatures can provide a very fast and flexible implementation of an EMFContainer.

Actually i am looking for UnitTests which are testing the BeanItemContainer. Since my implementation will be very similar i’d like to get an excelent knowledge about all the features (not an emf feature → means functions…) required to implement a properly working container.

Can anybody give me a hint whether there are unit tests and where i can find them.

Thanks in advance,
Florian Pirchner

There are tests
here
, but they could use a lot of clean-up and refactoring. If you would like to help with that, patches are very welcome (you can e.g. create a new ticket in
our trac
with a patch, and mention the ticket number here).

In any case, I would recommend using Vaadin 6.6 which has some improvements to containers, including a new mechanism for container filtering as well as an AbstractInMemoryContainer base class that AbstractBeanContainer and IndexedContainer now inherit.

With AIMC, the very minimum required to implement an in-memory container is to implement the getUnfilteredItem(Object id) method in a subclass of it. To support filtering, sorting etc., implement the interfaces mentioned in AIMC javadoc - most methods will typically be simple public methods calling the corresponding protected methods in AIMC. Adding and removing items or container properties also requires (usually simple) methods in the subclass.

You might also want to take a look at the interface VaadinPropertyDescriptor used by AbstractBeanContainer - in your case, it might even be possible to use AbstractBeanContainer and BeanItem but simply not use the (reflection-based) default property descriptors but your own ones. Just override the methods using the “model” field of ABC and implement your own EFeaturePropertyDescriptor and EFeatureProperty classes.

Thanks a lot for the detailed answer.
I already had a very short look at the unit tests. Think they will be very useful writing a container for EObjects.

Next week i am starting to analyse them in detail and publish my results here.

BTW: Florians work is part of the new (Open Source) redVaadin (http://redvaadin.org) project, where we also will publish informations on this.

ekke

It will take longer to finish the EMFContainer since i am finishing other parts of redVaadin according OSGi services. I decided to refactor the current architecture to make redVaadin very extendable.

I’ll post my result if i finished the container. But may take some time.

I built one of these for work - sorry can’t share the code. I can say a little bit about it. I would suggest you use EMF’s AdapterFactorys. I called my class an AdapterFactoryContainer because all the items within it were adapted using an AdapterFactory. The problem with relying on EFeatures is that sometimes you don’t want to render an EFeature or you want to render something that isn’t an EFeature. Using AdapterFactorys solves this problem.

You can’t use the the ItemProviders (what AdapterFactorys create) that get generated with a standard emf.ui project because those providers are specific to JFace’s interfaces, but it is pretty straight-forward to create providers that instead implement Vaadin’s Item and Property interfaces. The specific container I created was a hierarchical container and so I also had add to Vaadin’s existing data interfaces - for example, I added a “ParentItem” that made it easy to create an adapter that could return a list of children.

Just my $0.02. Good Luck.

Stephen

Thanks a lot for the hints!!!