[
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. :-)