[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [dali-dev] recent EMFBinding/Selection modifications
|
Markus,
I meant to send an email out yesterday afternoon, so here's my
explanation now. The bug I was trying to fix was that changing the
PersistentAttribute attributeMapping would cause problems. I tried to
solve this problem as you suggested a few weeks ago by having the
Persistence Properties 'Map As' combo viewer be a SelectionTracker, but
was unable to do this. My solution here was to only store the selected
object EClass and any possible parent EClasses because this simplified
things for the Dali case. I don't know that we need to try and have a
selection and binding framework that will work for other clients yet.
It is nearly impossible to do that in a first pass, so I felt like we
should at least make things work for Dali, keep it simple, and then we
can expand on it later if we feel that this is useful code for other
clients to use.
I have attached the original email that explained the bug I was seeing
and your solution for how to fix it. When I tried to make the 'Map As'
combo viewer an ISelectionTracker I hit issues because the combo viewer
does not actually hold emf objects, the emf object is created when the
model is told the the combo selection occurred. So, at the time of
selection, depending on who is informed first, the ISelectionTracker or
the emf model, the new AttributeMapping will not be in place in the
model yet. I can enter a bug in bugzilla if you would like to try and
fix this using the selection framework as it was before. It just seems
much simipler to me to only store the EClass of the object that is
actually selected, in the Dali project this will only ever be a
PersistenceFile, PersistentType, PersistentAttribute(possibly a few
others as our outline tree expands). It seemed to make more sense to
only store that one EClass and then you wont have as many problems with
child objects being replaced.
I agree with number 3 and am not sure why I didn't take that approach.
Karen
Markus Kuppe wrote:
Hi all,
todays CVS head shows a few changes to the selection and binding
projects which I don't understand or see the need for. %)
Whats the use cases that makes these changes necessary (btw. I'm missing
a corresponding enhancement bug in Bugzilla)?
The points I like to address/discuss are:
1. Indirect selection was renamed to parent selection. This fits
probably the current design of the Dali project, but a selection hasn't
necessarily a parent association.
Picture an EMF model that has no EMF associations between the EObjects.
With such a model it isn't possible to use the EMF reflection mechanism.
Therefor the original implementation delegates this to
ISelectionResolver, which is supposed to be implemented by the "client"
code (in this case the Dali project
(CompilationUnitSelectionTracker.getEObjectsAt(EObject))). In no way it
should be resolved by the ISelectionNotification. This class doesn't
know and shouldn't know about the EMF model associations.
I admit, the name "indirect", in retrospective, is in fact misleading
though. A closure of selections might be better.
2. In regards to my first point, "EClass selectableParentEClass" should
be removed from EMFSWTBinding(IEMFBindingAction anAction, EClass
anEClass, EClass selectableParentEClass, Control aControl, int
anEventType).
However this led to an interesting discussion between Christian and
myself this morning...
ISelectionDispatcher.getCurrentSelection(EClass) should be modified to
return the selection (selectee and closure of selectees) instead of the
selectee alone.
As already explained, EMFBinding isn't always able to navigate in the
EMF graph so we use the resolver mechanism again.
3. Let aside the first two arguments, the change to
PersistentOutlineSelectionListener
"aNotification.getSelectionForType(eClass, eClass)"
looks like a hack. Why not add a second method to ISelectionNotification
that takes one eClass as a parameter. That way we would avoid the if
statement in getSelectoinForType() too.
To sum things up, I suggest to revert back to yesterdays version and
to modify the return type
ISelectionDispatcher.getCurrentSelection(EClass).
--- Begin Message ---
Karen Moore wrote:
Hi Markus,
After further investigation, I don't think I understand how the
ISelectionDispatcher is supposed to work. Tak the use case I gave earlier
@Entity
public class Employee {
private Collection<Address> address;
}
and make address a one-to-many through the Persistence Properties view.
In this situation, the selection occured when I selected the address
attribute in the java editor. At this point the address mapping was an
InvalidMapping, so the SelectionDispatcher stored that information.
When I selected One to Many as the mapping type through the Persistence
Properties view, the MultiRelationshipComposite is built and along with
it the OrderByComposite. The OrderByComposite creates the EMFSWTBinding
and in that constructor the call to dispatcher.getCurrentSelection is
made. The SelectionDispatcher only has information about the selection
when the attribute was an InvalidMapping, not in its current state as a
OneToManyMapping, because a new selection did not occur. How is this
expected to work?
Hi,
the ISelectionDispatcher hence the selection project isn't supposed to
handle this use case at all. Its only purpose is to wrap low level
widget (UI) selections into EMF EObject selections and send these
selections to the registered listeners (ISelectionListeners).
The EMF binding on the other hand utilizes ISelectionDispatcher to get
the current "active/selected" EMF EObject in the UI. It doesn't care for
selection events and is therefor not an ISelectionListener.
In regards to the given use case I see two different solutions. The
first one would be, to add another constructor to EMFSWTBinding that
takes a real EMF EObject and not just the EClass. This way you don't
need to "query" the ISelectionDispatcher because you already have the
correct EObject.
In my opinion an even better solution is to make the part which creates
the new EMF EObject of the Properties View an ISelectionTracker.
Basically it changes the current selection, so it should notify the
ISelectionDispatcher.
That way we don't need to change the EMFSWTBinding as it still can use
the ISelectionDispatcher to get hold of the current EObject.
--
Regards,
Markus Kuppe
Versant GmbH, European Headquarters
Wiesenkamp 22b, 22359 Hamburg, Germany
+49(40)60990-215, http://www.versant.com
_______________________________________________
dali-dev mailing list
dali-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dali-dev
--- End Message ---
