Re: [dali-dev] Bug 128879/EMFBinding suggestions

[Brian Vosburgh <BRIAN.VOSBURGH@xxxxxxxxxx>]

 

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