[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[dali-dev] Bug 128879/EMFBinding suggestions
|
Hi,
as I promised yesterday here are my ideas for decoupling the
PersistencePropertiesView from the PersistenceOutline and preparing the
code the code for the extended JSR220Orm EMFBinding:
1.) Creating a new class EditorSelectionTracker (or whatever we want to
call it). This class is a listener on the IEditor to track the
selection. Probably a singleton in the Dali plugin. This Tracker listens
to IEditor activation/deactivation... and for selection events in the
Editor.
1.1) Some class to resolve the IEditor selection to our model element
(SelectionToModelResolver). The EditorSelectionTracker delegates the
resolving of the current selection to this class.
2.) Our views (or better the concrete EMFBinding) register them self as
listeners at the EditorSelectionTracker. Maybe they can register for a
concrete EMF model class (for example ManyToMany). Its independent of
the current activation state of the widget. We need the event even on
inactive (invisible) widgets. Otherwise we would need some kind of
refresh mechanism to update widgets when they are reactivated.
3.) If the EditorSelectionTracker catches a selection on a specific EMF
model element, it notifies all the registered bindings. The binding then
handles the event by updating the view and/or sending it to the model.
While working on it I found the class PageBookView which is a derived
class of ViewPart. From my understanding this class has most of the
functionality we implemented manually in PersistenceOutlineView. Maybe
its worth to refactor this too. For example it has already a PageBook
and manages between the different active composites.
Any comments?
So long...
Markus