Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » EditingDomain by EMF Data Binding
EditingDomain by EMF Data Binding [message #1230618] Sun, 12 January 2014 15:36 Go to next message
Emre T is currently offline Emre TFriend
Messages: 119
Registered: April 2013
Senior Member
Hello there!

I was hoping to get a little help regarding the use of EditingDomain-Support of EMF by its data binding issue.

I have an underlying EMF model. It's instances are shown in the generated reflective editors as usual. For its properties etc. to be shown beside the standard Properties View of Eclipse, I have further implemented an Eclipse view with a tree viewer (master) and a table editor (detail) regarding the Master-Detail-Approach. So far so good, the features are correctly shown, so the listeners, data binding context etc are working, but I need editing support for the structural features of the underlying model in my table viewer. I am using the EMFEditProperties/EMFEditObservables in my data binding, so I would eventually get the undo/redo support as well.

The problem for me is, that first of all, this is my first EMF data binding project, so I am to be honest new to this stuff. I first tried to use the standard EditingSupport from org.eclipse.jface.viewers.EditingSupport with various CellEditors (e.g. Text or ComboBox), but they are not working as with EMF.edit-Framework correctly as they supposed to (Or maybe they are and I am missing a point?). So I need to use the newer support for EMF, which is EditingDomain.

But the lack of tutorials etc. are not helping me much. I would be very happy, if someone could point me to the right direction. Is it even the right method for editing the elements in the table columns and boxes? Or it just delivers the support for the Undo/Redo, so that I still have to handle the editing with another way? It would be also great, if someone could post some code snippets to see, how the first steps are made. Every help will be appreciated. Thanks!
Re: EditingDomain by EMF Data Binding [message #1230684 is a reply to message #1230618] Sun, 12 January 2014 20:12 Go to previous messageGo to next message
Christophe Bouhier is currently offline Christophe BouhierFriend
Messages: 937
Registered: July 2009
Senior Member
On 12-01-14 16:36, Emre T wrote:
> Hello there!
>
> I was hoping to get a little help regarding the use of
> EditingDomain-Support of EMF by its data binding issue.
>
> I have an underlying EMF model. It's instances are shown in the
> generated reflective editors as usual. For its properties etc. to be
> shown beside the standard Properties View of Eclipse, I have further
> implemented an Eclipse view with a tree viewer (master) and a table
> editor (detail) regarding the Master-Detail-Approach. So far so good,
> the features are correctly shown, so the listeners, data binding context
> etc are working, but I need editing support for the structural features
> of the underlying model in my table viewer. I am using the
> EMFEditProperties/EMFEditObservables in my data binding, so I would
> eventually get the undo/redo support as well.
>
> The problem for me is, that first of all, this is my first EMF data
> binding project, so I am to be honest new to this stuff. I first tried
> to use the standard EditingSupport from
> org.eclipse.jface.viewers.EditingSupport with various CellEditors (e.g.
> Text or ComboBox), but they are not working as with EMF.edit-Framework
> correctly as they supposed to (Or maybe they are and I am missing a
> point?). So I need to use the newer support for EMF, which is
> EditingDomain.
>
> But the lack of tutorials etc.
try these:

http://tomsondev.bestsolution.at/2009/06/06/galileo-emf-databinding-part-1/

are not helping me much. I would be very
> happy, if someone could point me to the right direction. Is it even the
> right method for editing the elements in the table columns and boxes? Or
> it just delivers the support for the Undo/Redo, so that I still have to
> handle the editing with another way? It would be also great, if someone
> could post some code snippets to see, how the first steps are made.
> Every help will be appreciated. Thanks!
>
Re: EditingDomain by EMF Data Binding [message #1230687 is a reply to message #1230684] Sun, 12 January 2014 20:22 Go to previous messageGo to next message
Emre T is currently offline Emre TFriend
Messages: 119
Registered: April 2013
Senior Member
Thanks for the quick reply and yes, I know this tutorial. It was very helpful with the initial data binding and as an introduction into the new EMFEdit-Framework. But there isn't really much about the editing of the underlying model, except it states that it uses EditingDomain from EMF itself. The code furthermore has a lot of extra details in it and it makes the understanding of simpler aspects complicated. Plus, the project does not work, so I really can't let it run for e.g. debugging. Not that there any bugs, but I find debugging a great way to really understand the code and what it is doing.

Any further suggestions? Thanks!
Re: EditingDomain by EMF Data Binding [message #1230853 is a reply to message #1230687] Mon, 13 January 2014 08:35 Go to previous messageGo to next message
Christophe Bouhier is currently offline Christophe BouhierFriend
Messages: 937
Registered: July 2009
Senior Member
Hi,

With an EditingDomain, you have a CommandStack. EMF editing Commands are
executed on the stack. If you bind a model object instance with it's
feature(s) to a UI widget, it will use the Editingdomain to execute
commands on the commandstack, so effectively changing your model.

If you execute commands yourself
(editingDomain.getCommandStack().execute(...my command...) , the UI
widgets will be updated if you apply bidirectional binding with an
EMFDatabindingContext.

I use EMF databinding a lot, and to be honest I never bothered to
understand the inner specifics of EMF databinding. I just bind and it
works (Most of the time...:-) What you need to do some time is data type
conversion. So if your feature is an Enum type and your UI is a string,
you will need some sort of a conversion.


Or some times you need to bind the selection of a viewer.

See a binding example for a combo, populated with Enum and observed on
selection. (LevelKind is the Enum) it's set as an input on the viewer,
the selection is observed and bound to a feature which as a the Enum as
a data type. (So no data conversion here).

cmbLevelViewer = new ComboViewer(composite_1, SWT.NONE);

cmbLevelViewer.setContentProvider(new ArrayContentProvider());
cmbLevelViewer.setLabelProvider(new LabelProvider());
cmbLevelViewer.setInput(LevelKind.VALUES);

IEMFValueProperty toleranceLevelProperty = EMFEditProperties
.value(editingService.getEditingDomain(),
LibraryPackage.Literals.TOLERANCE__LEVEL);
IValueProperty selectionProperty = ViewerProperties.singleSelection();

context.bindValue(selectionProperty.observe(cmbLevelViewer),
toleranceLevelProperty.observe(tolerance), null, null);

Databinding can get more complex, with what I call the aggregate
pattern. this is where multiple UI widgets aggregate to a single model
feature for example.

If you can be very specific about which binding you are trying to
tackle, I am sure we can help you.


On 12-01-14 21:22, Emre T wrote:
> Thanks for the quick reply and yes, I know this tutorial. It was very
> helpful with the initial data binding and as an introduction into the
> new EMFEdit-Framework. But there isn't really much about the editing of
> the underlying model, except it states that it uses EditingDomain from
> EMF itself. The code furthermore has a lot of extra details in it and it
> makes the understanding of simpler aspects complicated. Plus, the
> project does not work, so I really can't let it run for e.g. debugging.
> Not that there any bugs, but I find debugging a great way to really
> understand the code and what it is doing.
>
> Any further suggestions? Thanks!
Re: EditingDomain by EMF Data Binding [message #1232109 is a reply to message #1230618] Thu, 16 January 2014 08:56 Go to previous messageGo to next message
Lorenzo Bettini is currently offline Lorenzo BettiniFriend
Messages: 1754
Registered: July 2009
Location: Firenze, Italy
Senior Member
On 12/01/2014 16:36, Emre T wrote:
> Hello there!
>
> I was hoping to get a little help regarding the use of
> EditingDomain-Support of EMF by its data binding issue.
>
> I have an underlying EMF model. It's instances are shown in the
> generated reflective editors as usual. For its properties etc. to be
> shown beside the standard Properties View of Eclipse, I have further
> implemented an Eclipse view with a tree viewer (master) and a table
> editor (detail) regarding the Master-Detail-Approach. So far so good,
> the features are correctly shown, so the listeners, data binding context
> etc are working, but I need editing support for the structural features
> of the underlying model in my table viewer. I am using the
> EMFEditProperties/EMFEditObservables in my data binding, so I would
> eventually get the undo/redo support as well.
>
> The problem for me is, that first of all, this is my first EMF data
> binding project, so I am to be honest new to this stuff. I first tried
> to use the standard EditingSupport from
> org.eclipse.jface.viewers.EditingSupport with various CellEditors (e.g.
> Text or ComboBox), but they are not working as with EMF.edit-Framework
> correctly as they supposed to (Or maybe they are and I am missing a
> point?). So I need to use the newer support for EMF, which is
> EditingDomain.
>
> But the lack of tutorials etc. are not helping me much. I would be very
> happy, if someone could point me to the right direction. Is it even the
> right method for editing the elements in the table columns and boxes? Or
> it just delivers the support for the Undo/Redo, so that I still have to
> handle the editing with another way? It would be also great, if someone
> could post some code snippets to see, how the first steps are made.
> Every help will be appreciated. Thanks!
>

Hi

you might be interested in our new Eclipse project Emf Parsley, which
provides a set of reusable UI components based on EMF (e.g., trees,
tables, forms, views and editors) that can be used in your EMF-based
plugin out-of-the-box. Under the hood databinding and editing domain
are used extensively.

http://projects.eclipse.org/projects/modeling.emf-parsley

and here's the EclipseCon presentation if you want to have a quick look
at its features:
http://www.youtube.com/watch?feature=plpp&v=-S8mh5p-ChE&p=PLy7t4z5SYNaQGJrjB5CFs3tSaulL6yiNU&app=desktop

cheers
Lorenzo

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book
Re: EditingDomain by EMF Data Binding [message #1235213 is a reply to message #1232109] Thu, 23 January 2014 20:43 Go to previous messageGo to next message
Emre T is currently offline Emre TFriend
Messages: 119
Registered: April 2013
Senior Member
Thanks a lot for the quick replies. Well, I believe I first have to make my approach and project clear. It is kind of a unique situation.

First of all, the underlying EMF models I am working with are somehow different from the examples we see a lot around. The idea behind them is similar to UML profiles and stereotypes. The users are creating their own models with different features (attributes and references). So in the end, I only have the meta-model in the hand for the data binding and I don't know which structural features the models from the users are going to be there. Therefor, I have to search EStructuralFeatures of the model being observed from the editor and first eliminate the hard-coded/ generated features of the meta-model, so that only the features created by the users will be shown in the cells of the tableviewer.

The UI looks like this: There is a treeviewer completely implemented, which listens to active workbench editors, tests whether the editor has a valid model instance, searches for the specific elements of the model (which have these by-the-user-custom-created attributes) and shows them accordingly with their name. In this case the treeviewer is the master in the master-detail-scenario. Second, in the same view I have a tableviewer, which acts like a the detail part. There are two columns. The first one shows the names of the searched structural features and the secon column should show their values, which eventually have to be edited.

Because of these specific structural features I can't just deliver a data binding based on the known elements, but I have to search them. I have implemented a utility class (EFeatureSorter) for this. The method is as follows:

	public static EStructuralFeature getFeature() {
		
		EObject sa = XYZModelPackage.Literals.SA;
		EList<EStructuralFeature> eAllStructuralFeatures = sa.eClass().getEAllStructuralFeatures();

		if (!eAllStructuralFeatures.isEmpty()) {
			try {
				for (EStructuralFeature feature : eAllStructuralFeatures) {
					if (feature instanceof EAttribute) {
							return feature;
						}
				}
			} catch (Exception e) {
				e.printStackTrace();
			}
		} 
		return null;	
	}


There is also a change listener for the elements in treeviewer, which acts like a mediator and sets the values of the master: It looks like this:

			private static IObservableValue master = new WritableValue();
	                private static SA masterStereotypeApplication;

                        ...

                        IObservableValue treeObservables = ViewerProperties.singleSelection().observe(treeViewer);
			treeObservables.addValueChangeListener(new IValueChangeListener() {
				public void handleValueChange(ValueChangeEvent event) {
					if (event.diff.getNewValue() instanceof SA) {
						masterStereotypeApplication = (SA) event.diff.getNewValue();
						master.setValue(masterStereotypeApplication.getStereotype()); 
                                                //getStereotype() delivers the details needed to shown in the tableviewers columns
                                                //treeviewer show the elements which holds these stereotypes!
					} else if (event.diff.getNewValue() instanceof BLABLA) {
                                          ...
					} 
				}
			});	


And the table viewer with the databinding and label providers look like this:

                 	private EditingDomain editingDomain = new AdapterFactoryEditingDomain(adapterFactory, commandStack, new HashMap()); 
	                private EMFDataBindingContext dbc = new EMFDataBindingContext();


                        ...

{
                        ObservableListContentProvider contentProvider = new ObservableListContentProvider();
			
			IObservableMap[] observeMaps = EMFEditObservables.observeMaps(editingDomain, contentProvider.getKnownElements(), 
					new EStructuralFeature[]{EFeatureSorter.getFeature()});
			
			IValueProperty property = EMFEditProperties.value(editingDomain, EFeatureSorter.getFeature());

			tableViewer.setContentProvider(contentProvider);
			tableViewer.setLabelProvider(new ObservableMapLabelProvider(observeMaps) {});
			
			IObservableList masters = EMFEditObservables.observeDetailList(Realm.getDefault(), editingDomain, master, Literals.ECLASS__EALL_ATTRIBUTES);
			tableViewer.setInput(masters);
			
		    {	    			
		    	twc_stereotype = new TableViewerColumn(tableViewer, SWT.LEFT);
		    	tblclmnFirstColumn = twc_stereotype.getColumn();
		    	tblclmnFirstColumn.setWidth(200);
		    	tblclmnFirstColumn.setText(STEREOTYPE);
		    	
		    	twc_stereotype.setLabelProvider(new CellLabelProvider() {
					@Override
					public void update(ViewerCell cell) {
						Object obj = cell.getElement();
						if (obj instanceof EAttribute) {
							cell.setText(((EAttribute) obj).getName());
						}
					} 
				});
		    }
		    		    
		    {		    	    	
		    	twc_value = new TableViewerColumn(tableViewer, SWT.NONE);
		    	tblclmnSecondColumn = twc_value.getColumn();
		    	tblclmnSecondColumn.setWidth(200);
		    	tblclmnSecondColumn.setText(VALUE);
		    	
		    	twc_value.setLabelProvider(new CellLabelProvider() {
					@Override
					public void update(ViewerCell cell) {
						Object obj = cell.getElement();
						if (obj instanceof EAttribute) {
							cell.setText(stereotypeApplication.eGet((EAttribute) obj).toString());	
						}
					}
		    	});
				
		    	
		    	twc_value.setEditingSupport(EMFObservableValueEditingSupport.create(tableViewer, dbc, new TextCellEditor(table), 
		    			CellEditorProperties.control().value(WidgetProperties.text(SWT.Modify)), property));
                    }

}


The code is not complete, there is going to be a huge refactoring in the end, when I get the functionality right.

What happens now is so; the treeviewer functions well. The first column of the table viewer shows the name of the selected structural features (master elements), and the second column shows their values. But whenever I click on the cells of the second column, the editable part becomes suddenly the name (as in the first column) of the structural feature, I can type whatever I want, but then nothing happens when I click somewhere else, and it shows again the unchanged values of the structural features.

Also the structural features getting shown in the tableviewer are not just String. They can be from different types; Boolean, ENUM etc. I believe this brings with it another non-trivial problem, which is that the different cells of the second column should be able to show different type of elements. Therefor, the different cells need to be edited also differently. String and integers etc. as simple Strings. Enums and Booleans with a drop-down box. Just like the standard Properties view of the Eclipse. But I want to approach the problem iteratively, so first simple editable text cells should be enough.

I am really lost to be honest. But I believe there might also be a problem with my data binding, or maybe there are better solutions to what I am trying to do. Any help will be appreciated. Thank you very much!

[Updated on: Thu, 23 January 2014 20:57]

Report message to a moderator

Re: EditingDomain by EMF Data Binding [message #1235442 is a reply to message #1232109] Fri, 24 January 2014 11:37 Go to previous messageGo to next message
Emre T is currently offline Emre TFriend
Messages: 119
Registered: April 2013
Senior Member
Lorenzo Bettini wrote on Thu, 16 January 2014 03:56


Hi

you might be interested in our new Eclipse project Emf Parsley, which
provides a set of reusable UI components based on EMF (e.g., trees,
tables, forms, views and editors) that can be used in your EMF-based
plugin out-of-the-box. Under the hood databinding and editing domain
are used extensively.

http://projects.eclipse.org/projects/modeling.emf-parsley

and here's the EclipseCon presentation if you want to have a quick look
at its features:
http://www.youtube.com/watch?feature=plpp&v=-S8mh5p-ChE&p=PLy7t4z5SYNaQGJrjB5CFs3tSaulL6yiNU&app=desktop

cheers
Lorenzo


Hello, I will definitely take a look at this, but I have already implemented a custom view and I am not interested in all the features of a model element. Though the concept of using the editable elements out-of-the-box seems very impressive, the tool integration into custom JFace/Swing constructs will play a more important role for me. So I will have to take a closer look at your tool.

[Updated on: Fri, 24 January 2014 21:33]

Report message to a moderator

Re: EditingDomain by EMF Data Binding [message #1236155 is a reply to message #1235442] Sun, 26 January 2014 11:22 Go to previous messageGo to next message
Emre T is currently offline Emre TFriend
Messages: 119
Registered: April 2013
Senior Member
Hello again, any ideas, where I might be wrong?

I am guessing that the general issue is because of the need to dynamically sort the EAttributes at the run time. Since all other data binding projects I have been working and testing on were OK, and in those I have been using the generated EMF packages of the models and accessing the attributes directly in bindings.

Thanks again!
Re: EditingDomain by EMF Data Binding [message #1244609 is a reply to message #1236155] Wed, 12 February 2014 15:52 Go to previous messageGo to next message
Emre T is currently offline Emre TFriend
Messages: 119
Registered: April 2013
Senior Member
Hello again,

I was wondering, if there still might be any help regarding the situation?

Thanks!
Re: EditingDomain by EMF Data Binding [message #1245819 is a reply to message #1244609] Fri, 14 February 2014 10:09 Go to previous messageGo to next message
Christophe Bouhier is currently offline Christophe BouhierFriend
Messages: 937
Registered: July 2009
Senior Member
On 12-02-14 16:52, Emre T wrote:
> Hello again,
>
> I was wondering, if there still might be any help regarding the situation?

Hi, Sorry I think your question got lost somewhere in the discussion.

Is this your question? Please confirm we will help you.

" I need editing support for the structural features of the underlying
model in my table viewer. I am using the
EMFEditProperties/EMFEditObservables in my data binding, so I would
eventually get the undo/redo support as well. "


> Thanks!
Re: EditingDomain by EMF Data Binding [message #1245836 is a reply to message #1245819] Fri, 14 February 2014 10:31 Go to previous messageGo to next message
Emre T is currently offline Emre TFriend
Messages: 119
Registered: April 2013
Senior Member
Hello,

well, actually in the mean time, my problem has shifted a little bit and now I am trying to figure out the following issue, for which I have also opened a separate topic.

http://www.eclipse.org/forums/index.php/t/648930/

Maybe you can help regarding this situation.

Thanks!
Re: EditingDomain by EMF Data Binding [message #1245849 is a reply to message #1245836] Fri, 14 February 2014 10:53 Go to previous message
Christophe Bouhier is currently offline Christophe BouhierFriend
Messages: 937
Registered: July 2009
Senior Member
On 14-02-14 11:31, Emre T wrote:
> Hello,
>
> well, actually in the mean time, my problem has shifted a little bit and
> now I am trying to figure out the following issue, for which I have also
> opened a separate topic.
Ah, I just replied to that one.
>
> http://www.eclipse.org/forums/index.php/t/648930/
>
> Maybe you can help regarding this situation.
>
> Thanks!
Previous Topic:Call methods that need plugin's resource factory from launch configuration
Next Topic:Converting an XMI to XML Resource
Goto Forum:
  


Current Time: Mon Aug 19 22:21:53 GMT 2019

Powered by FUDForum. Page generated in 0.02546 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top