[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [dali-dev] EMF binding/selection committed
|
I have another question, do we want to be setting things on the emf
model through the emf EditingDomain command stack instead of setting
values directly on the emf objects?
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. :-)
