Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [dali-dev] EMF binding/selection committed

A few comments:

In EMFSWTBinding the eAdapter is never removed when the composite is disposed. So, if you close the persistence properties view, the perspective, or the window and then reopen it, you will hit problems with the old widget trying to update to changes in the model. Also the EmfBinding is being added as an adapter twice, first in EMFOrderByBindingAction line 63 and then in EMFSWTBinding line 42.

In EMFOrderByBindingAction the call to combo.getDisplay().timerExec(400, runnable); You need to check that the widget is not disposed in the runnable.run() according to the Display.timerExec() javadocs. This will be a problem if you updated the java and then closed the persistence properties view before the runnable is run.

EMFBinding call to Display.getDefault().syncExec(runnable);
I am concerned with deadlocks in this situation. We've had problems that I think are related to this in Dali, but we may have been misuing other aspects of emf or swt. Do you know whether this will be a problem with the emf binding framework? I can't say that I have a full grasp on this issue.

Not sure why we need EMFBindingAction, providing an abstract class doesn't seem very useful if you have to implement all the methods anyway.


Karen




Markus Kuppe wrote:

Hi,

as we discussed yesterday on the conference call I've just committed the
refactoring/porting of the emf binding/selection "framework".

Besides adding two new projects org.eclipse.dali.selection and
org.eclipse.dali.binding I had to modify/move several classes in the ui
project as well. The old ui code still works with the new binding though
so we can do a step by step transition to the new binding.

The selection project tracks ui selection events and resolves them into
EMF objects. After that a selection notification is send to the
listeners containing the eobject.

The binding project is responsible for building a relationship between a
ui component (widget/viewer/...) and EMF object(s). There is always a
1:1:1 relationship between a binding/widget/eobj. In the end its some
kind of association class that handles modifications in either the ui or
the model.

So what are the necessary steps to use the new binding. I will describe
it for the OrderBy here.
The class org.eclipse.dali.ui.composites.OrderByComposite is the layout
class. It is just responsible for the ui code and to create and attach a
new EMF binding to the widget. It doesn't know about the concrete EMF
object though. It only declares the EClass the binding should handle.
The other class
org.eclipse.dali.ui.binding.action.EMFOrderByBindingAction represents
some kind of function pattern. The doModel, doView and doInit methods
are called each time an modification happens in the view, the model or
for the latter if the binding was initialized.
This class is specific to each concrete binding. However its unnecessary
to check for event loops or such things in each binding action because
this is done in the general EMFBinding.

Showing the associated ui component to the current selection in for
example the editor is handled in a different part.
org.eclipse.dali.ui.selection.listener.PersistentOutlineSelectionListener
 internally uses a PageBook (or a wrapper class PageBookManager) to
activate the associated TreeViewer for the current PersistenceFile
selection. The
org.eclipse.dali.ui.selection.listener.PersistentPropertiesListener does
the same for the PersistentPropertiesView. Both classes create the
associated ui components (composites) for the current
ISelectionNotification (EMF obj) and disposes the composites if the eobj
gets deselected.

But before I go to much into detail you should dig through the code
yourself. I tried to comment the important interfaces and classes with
javadoc.
Please send questions/comments/bugs to me. I'm eager to get some
feedback. :-)



Back to the top