A few minor comments in line:
Markus Kuppe wrote:
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.
I'm not sure I see how the EditorSelectionTracker would work as
a singleton. How would it know to start and/or stop listening to a
particular IEditorPart? What is EditorSelectionTracker's state? And
what methods do you envision it implementing?
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.
I think I like the idea of the EMFBinding being the listener,
but I don't understand what you mean by "concrete EMF model class". I
can interpret that phrase a number of different ways. :-) Maybe you
could provide an example of the method signature?
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.
I'm a little confused here. Would the events fired by the
EditorSelectionTracker cause updates to the model? If so, could you
give an example?
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.
Did you mean that the PageBookView could be used for the
PersistencePropertiesView (as opposed to
the PersistenceOutlineView)? If you meant
_Outline_, then I don't understand how the PageBookView could be used.
If you meant _Properties_, then I can't speak for why PageBookView was
not used - you'll have to ask the perpetrators. :-)
Brian
|