On 2/23/06, Markus Kuppe <mkuppe@xxxxxxxxxxx> 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.
It can not be a singleton because you can have multiple edit parts and multiple windows.
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.
The SelectionToModelResolver should be obtained by adapting the
editor, this way we can have different resolvers for different
editors (java/xml), and new editors (say added by extenders) can create
their own resolvers
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.
We may need to do a little bit more that just pass the eClass, what if
a widget is displaying some property of a column, it needs to know when
navigation happened to the columns owning attribute.
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.
No, I think the binding widget can listen for EMF events. The
EditorSelectionTracker should track selection and not edits. This will
also require a VERY complex system and adding and removing listeners
and delegating event calls. Edits to and from the widget and the model
should be handled by the binding framework.
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.
On JSR220 we did try to use PageBookView, but it did not work for use
in the end, I can not remember way thou, sorry. We ended up
copy-pasting code from it. I think it was the way it handled the
page changes, it expects one page per editor and we have lots of page
for one editor.
Any comments?
So long...
Markus
_______________________________________________
dali-dev mailing list
dali-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dali-dev
