[dali-dev] Bug 128879/EMFBinding suggestions

[Markus Kuppe <mkuppe@xxxxxxxxxxx>]

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