Home » Modeling » EMF » EditingDomain by EMF Data Binding
EditingDomain by EMF Data Binding [message #1230618] |
Sun, 12 January 2014 15:36 |
Emre T 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 |
Christophe Bouhier 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 #1230853 is a reply to message #1230687] |
Mon, 13 January 2014 08:35 |
Christophe Bouhier 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 |
|
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
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
Re: EditingDomain by EMF Data Binding [message #1235213 is a reply to message #1232109] |
Thu, 23 January 2014 20:43 |
Emre T 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 |
Emre T 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
|
|
| | | | | |
Goto Forum:
Current Time: Thu Sep 19 00:45:24 GMT 2024
Powered by FUDForum. Page generated in 0.05033 seconds
|