Community
Participate
Working Groups
Currently CanonicalConnectionEditPolicy contains following methods: abstract protected List getSemanticConnectionsList(); abstract protected EObject getSourceElement(EObject relationship); abstract protected EObject getTargetElement(EObject relationship); getSemanticConnectionsList should return a list of semantic elements represented by the connection on diagram. getSource/TargetElement are used to determine source/target of the connection represented on diagram based on semantic element "relationship" passed as a parameter. In this implementation there is no possibility to update connections which is representer as a reference in the semantic model. For example, on ECore diagram a set of supertypes of EClass is represented as a set of "generalization" links from this EClass to it's supertypes. As a result, there is no EObject instance which could be returned from getSemanticConnectionsList for such a "generalization" link - this link is just a reference inside EClass.getESuperTypes() list. CanonicalConnectionEditPolicy should be refactored to support updating such a links.
I propose describe a link by an instance of the following class: public class LinkDescriptor { private EObject mySource; private EObject myDestination; private EObject myLinkElement; private String mySemanticHint; private IAdaptable mySemanticAdapter; public LinkDescriptor(EObject source, EObject destination, EObject linkElement, String semanticHint) { this(source, destination, semanticHint); myLinkElement = linkElement; mySemanticAdapter = new EObjectAdapter(linkElement); } public LinkDescriptor(EObject source, EObject destination, IElementType elementType, String semanticHint) { this(source, destination, semanticHint); myLinkElement = null; final IElementType elementTypeCopy = elementType; mySemanticAdapter = new IAdaptable() { public Object getAdapter(Class adapter) { if (IElementType.class.equals(adapter)) { return elementTypeCopy; } return null; } }; } private LinkDescriptor(EObject source, EObject destination, String semanticHint) { mySource = source; myDestination = destination; mySemanticHint = semanticHint; } protected EObject getSource() { return mySource; } protected EObject getDestination() { return myDestination; } protected EObject getLinkElement() { return myLinkElement; } protected String getSemanticHint() { return mySemanticHint; } protected IAdaptable getSemanticAdapter() { return mySemanticAdapter; } } As a result: - getSourceElement/getTargetElement methods should be removed from the CanonicalConnectionEditPolicy - getSemanticConnectionsList() method should return a list of LinkDescriptor instances - Code matching diagram link with the link which was returned from getSemanticConnectionsList() will looks like: Edge nextDiagramLink = (Edge) diagramLinks.next(); EObject diagramLinkObject = nextDiagramLink.getElement(); EObject diagramLinkSrc = nextDiagramLink.getSource().getElement(); EObject diagramLinkDst = nextDiagramLink.getTarget().getElement(); String diagramLinkSemanticHint = nextDiagramLink.getType(); for (Iterator modelLinkDescriptors = myLinkDescriptors.iterator(); modelLinkDescriptors.hasNext();) { LinkDescriptor nextLinkDescriptor = (LinkDescriptor) modelLinkDescriptors.next(); if (diagramLinkObject == nextLinkDescriptor.getLinkElement() && diagramLinkSrc == nextLinkDescriptor.getSource() && diagramLinkDst == nextLinkDescriptor.getDestination() && diagramLinkSemanticHint == nextLinkDescriptor.getSemanticHint()) { // Link was matched! Should not be removed/added } } - In createConnectionView we can use LinkDescriptor.getSemanticAdapter() method instead of creating new adapter instance inside CanonicalConnectionEditPolicy as a result we'll be able to correctly create links without semantic elements as well.
In addition I suggest to change getSource/TargetEditPartFor() methods to serach for editpart more precisely because current logic is not working for some cases (ECore example). I can propose a patch and attach it to this request, but I do not think it is reasonable because I'm suggesting quite a big refactoring and I suppose all these changes should be reviewed/approved by a runtime team.
Mohammed is evaluating CanonicalEditPolicy currently
Is the generator team blocked by this? I think this could be best addressed as an enhancement post 3.2...
No. Correcponfing logic is already introduced in a templates as a workaround for current problems, so generated code works well. IMHO we can fix it in a runtime later - for first release it is enough to fully support reference-only links updating by generated code only.
Moving to enhancement to be considered post 3.2
More comments on Comments #2 of Alex : Currently getSource/TargetEditPartFor() methods implementation does not work for me too. I have similar case as Ecore example. I try to create a Canonical view of my model object in memory. My model has not been saved and its element does not have id attribute. As a result, the sementic element is not registered in elementToEditPartsMap of DiagramGraphicalViewer and not found by getSource/TargetEditPartFor. This enhancement is very important to my project.
Any chance to get it fixed in GMF 2.0? We are planning refactoring of generated CanonicalEditPolicy for 2.0 to get rid of existing synchronization problems, so it will be perfect if generation part could be changed in-synch with runtime.
We plan to address various canonical issues in 2.0. We will not have time to do this in 2.0 M3 however.
During the last teleconference it was suggested to place the logic updating "reference-only" links (representing reference in the semantic model) into EditPart.refreshSourceConnections/refreshTargetConnections methods. Mohammed, please correct me if I'm wrong.
Here I’m trying to compare functionality available in EditPart.refreshSource/TargetConnections() and CanonicalConnectionEditPolicy to make it clear that CanonicalConnectionEditPolicy is a proper place to implement Canonical behavior for reference-only links: 1. EditPart. refreshSource/TargetConnections() were created for updating incoming/outgoing GEF connections (links) in accordance with the underlying model contents (notation model Edge instances). Corresponding EditPart listen for the notifications from notation model elements and call these methods if necessary (see ShapeNodeEditPart.handleNotificationEvent() and ConnectionNodeEditPart.handleNotificationEvent()). This logic perfectly works with updating diagram on any changes in the notation model. 2. CanonicalEditPolicy extended by CanonicalConnectionEditPolicy, contains the following logic + utility methods: a. CanonicalElementAdapter used by this class and subclasses to create new instance of View b. _registry Map associating semantic model element with all currently activated CanonicalEditPolicies for it (having ViewUtil.resolveSemanticElement((View)host().getModel()) == this semantic model element) with static accessors. This registry provides the possibility to get all active CanonicalEditPolicies for any semantic model element and call refresh(). This functionality could be useful for processing complex semantic updates then the notification came from one semantic model element should force update of view representing another semantic model element. c. getSemanticChildrenList() – abstract method to be implemented in subclasses to provide common semantic update logic with particular semantic model contents. d. Utility method for deleting view instances. e. Utility methods for creating views in the correct position in the list of child views. f. Activate code registering listeners for the semantic model element + performing initial refresh on activating the EditPolicy. g. Deactivate code unregistering corresponding semantic model listeners. h. Enabling/Disabling CanonicalUpdates by setting/unsetting CanonicalStyle.canonical attribute. i. Invoke refresh() on corresponding notification from the semantic model j. Utility methods for setting views mutable/immutable k. refreshSemanticChildren() method comparing existing semantic model children with the notation model children and removing “orphaned” views + creating new for new semantic model elements 3. CanonicalConnectionEditPolicy was created to “update notation model elements having underlying semantic model element” (quotation from last teleconference) and should do nothing with diagram links created based on the existing reference in the semantic model (because there is no semantic model elements attached to such a connections). Contains following functionality: a. Abstract methods getSemanticConnectionsList(),getSourceElement(),getTargetElement() to be implemented by subclasses – set of helpers to match domain model link with the existing notation model link. b. Utility method allowing CanonicalBevahior for the connection based on EditPolicyRoles. CANONICAL_ROLE or source/target Editparts c. Utility methods returning source/targetEditPart for some semantic model element representing connection. d. Utility method for creating Edge for some semantic model element. e. refreshSemantic() method implementation first calling super. refreshSemantic() and then performing update of the connections. f. refreshSemanticConnections() method iterating through all the existing notation model Edges, comparing them with the semantic model elements and deleting obsolete Edges/adding new one (like in the CanonicalEditPolicy). Conclusion: It looks obvious that to place Canonical update logic for reference-only links into EditPart. refreshSource/TargetConnections() one have to implement all the functionality listed in 2. and 3. once more. To implement kind of “limited” CanonicalUpdate we have to copy: - utility methods creating/deleting notation model elements - logic comparing notation model contents with the semantic one - install semantic model listeners once more Corresponding super-classes for all the generated EditParts should be created and committed to the runtime to prevent generated code from huge code duplications. My position is: The proper place to synchronize notation model Edges with the semantic model contents for reference-only links is CanonicalConnectionEditPolicy and it looks very natural taking into account functionality already implemented in CCEP (see above). Mohammed, please post your arguments not to support CanonicalUpdate for reference-based links here.
(In reply to comment #11) > Here I¡¦m trying to compare functionality available in > EditPart.refreshSource/TargetConnections() and CanonicalConnectionEditPolicy to > make it clear that CanonicalConnectionEditPolicy is a proper place to implement > Canonical behavior for reference-only links: > 1. EditPart. refreshSource/TargetConnections() were created for updating > incoming/outgoing GEF connections (links) in accordance with the underlying > model contents (notation model Edge instances). Corresponding EditPart listen > for the notifications from notation model elements and call these methods if > necessary (see ShapeNodeEditPart.handleNotificationEvent() and > ConnectionNodeEditPart.handleNotificationEvent()). This logic perfectly works > with updating diagram on any changes in the notation model. > 2. CanonicalEditPolicy extended by CanonicalConnectionEditPolicy, contains > the following logic + utility methods: > a. CanonicalElementAdapter used by this class and subclasses to create new > instance of View > b. _registry Map associating semantic model element with all currently > activated CanonicalEditPolicies for it (having > ViewUtil.resolveSemanticElement((View)host().getModel()) == this semantic model > element) with static accessors. This registry provides the possibility to get > all active CanonicalEditPolicies for any semantic model element and call > refresh(). This functionality could be useful for processing complex semantic > updates then the notification came from one semantic model element should force > update of view representing another semantic model element. > c. getSemanticChildrenList() ¡V abstract method to be implemented in > subclasses to provide common semantic update logic with particular semantic > model contents. > d. Utility method for deleting view instances. > e. Utility methods for creating views in the correct position in the list > of child views. > f. Activate code registering listeners for the semantic model element + > performing initial refresh on activating the EditPolicy. > g. Deactivate code unregistering corresponding semantic model listeners. > h. Enabling/Disabling CanonicalUpdates by setting/unsetting > CanonicalStyle.canonical attribute. > i. Invoke refresh() on corresponding notification from the semantic model > j. Utility methods for setting views mutable/immutable > k. refreshSemanticChildren() method comparing existing semantic model > children with the notation model children and removing ¡§orphaned¡¨ views + > creating new for new semantic model elements > 3. CanonicalConnectionEditPolicy was created to ¡§update notation model > elements having underlying semantic model element¡¨ (quotation from last > teleconference) and should do nothing with diagram links created based on the > existing reference in the semantic model (because there is no semantic model > elements attached to such a connections). Contains following functionality: > a. Abstract methods > getSemanticConnectionsList(),getSourceElement(),getTargetElement() to be > implemented by subclasses ¡V set of helpers to match domain model link with the > existing notation model link. > b. Utility method allowing CanonicalBevahior for the connection based on > EditPolicyRoles. CANONICAL_ROLE or source/target Editparts > c. Utility methods returning source/targetEditPart for some semantic model > element representing connection. > d. Utility method for creating Edge for some semantic model element. > e. refreshSemantic() method implementation first calling super. > refreshSemantic() and then performing update of the connections. > f. refreshSemanticConnections() method iterating through all the existing > notation model Edges, comparing them with the semantic model elements and > deleting obsolete Edges/adding new one (like in the CanonicalEditPolicy). > Conclusion: It looks obvious that to place Canonical update logic for > reference-only links into EditPart. refreshSource/TargetConnections() one have > to implement all the functionality listed in 2. and 3. once more. To implement > kind of ¡§limited¡¨ CanonicalUpdate we have to copy: > - utility methods creating/deleting notation model elements > - logic comparing notation model contents with the semantic one > - install semantic model listeners once more > Corresponding super-classes for all the generated EditParts should be created > and committed to the runtime to prevent generated code from huge code > duplications. > My position is: The proper place to synchronize notation model Edges with the > semantic model contents for reference-only links is > CanonicalConnectionEditPolicy and it looks very natural taking into account > functionality already implemented in CCEP (see above). > Mohammed, please post your arguments not to support CanonicalUpdate for > reference-based links here. Hi Alex; Thank you for explaining how Gef and edit policies work :) But you did not need to write this long comment to convince me since I¡¦m already convinced ƒº I think we have a miscommunication here. In the conference call I said that Canonical edit policies had been designed to synchronize semantic elements (EObjects) with Views, this is not an opinion it is a fact. I'm not saying it is the best but this is what we have today I did not say that I¡¦ll close this request, because I think there is a value in supporting that with only one condition, we have to make sure that adding this support will not affect existing clients when it comes to performance or memory consumption ( I mean the temporary memory consumption during the refresh), which I think is achievable by a sub classed canonical edit policy What I suggested was a workaround, regarding the points you mentioned in your reply I did not get some of them for example you talked about adding listeners and removing them if I¡¦m doing a canonical refresh why would I need to add a listener doe snot the edit part listen already to the semantic element, also regarding refresh on activating does not the edit part refresh any way on activating as well, any way i would not get into this argument since we both agree on the conclusion. So, to make the long story short, I agree we need to add this support and i did not plan to close the request but it will be lower priority with respect to the other canonical edit polices issues. does the conclusion make sense to you ?
>I think we have a miscommunication here. In the conference call I said >that Canonical edit policies had been designed to synchronize semantic elements >(EObjects) with Views, this is not an opinion it is a fact. I'm not saying >it is the best but this is what we have today Sure I see it. And my point is: to drive GMF project forward we have to change assumptions used while designing CanonicalEditPolicies and modify it in accordance. What I’m going to do is to create requirements for the Canonical/Non-Canonical containers/diagrams on wiki to finalize it. >I did not say that I¡¦ll close this request, because I think there is a >value in supporting that with only one condition, we have to make sure >that adding this support will not affect existing clients when it comes >to performance or memory consumption ( I mean the temporary memory >consumption during the refresh), which I think is achievable by a >sub classed canonical edit policy 1. Do not think old clients will have any additional performance or memory problems if we will change API in a compatible way, but corresponding methods will not be implemented on their side.. 2. We always receive the answer “it is not possible due to the legacy code”.. In this particular case I do not see any problems on introducing completely new CanonicalEditPolicy into Runtime, mark old one as “deprecated” and later on remove old classes from API. What do you think about this solution? I can create a patch for you. >reply I did not get some of them for example you talked about adding >listeners and removing them if I¡¦m doing a canonical refresh why would I need Yes, that was my mistake – EditPart of source node of the link (responsible for canonical link refresh) is listening for semantic source node, but I have to copy-paste the logic of shouldHandleNotificationEvent() at least the part selecting correct features of underlying domain model element and triggering update if necessary. >element, also regarding refresh on activating does not the edit part refresh >any way on activating as well Yes, it does. >So, to make the long story short, I agree we need to add this support and i did >not plan to close the request but it will be lower priority with respect to the >other canonical edit polices issues. In this case I do not understand why you while realizing all these facts suggest me to place corresponding logic into EditPart.refreshSource/TargetConnections() during the teleconference.. It looks strange for me. ;-) Concerning the priorities – I will not say that this request has lower priorities then all the rest – we have Ecore diagram example generated (most used example I hope) and this example works with synchronized diagram + reference-based links. Once more, this problem was corrected on generator side by generating additional logic to the CanonicalConnectionEditPolicy, but I do not think this is a good way to work with Runtime part.. So, to make it short: I will insist on fixing all the mentioned problems with CanonicalEditPolicies all together. My opinion is: we will introduce huge number of unnecessary code leading us to the unclear API and adding garbage to the open-source code if we will fix all CanonicalEditPolicies problems without total refactoring of corresponding classes. If you think this is impossible due to the compatibility problems with legacy code I suggest to create new CanonicalEditPolicyV2 and CanonicalConnectionEditPolicyV2 in the runtime and mark old classes as deprecated. Another option is to develop different updating mechanism and use it throughout GMF. I think use cases I will create on wiki will help us to get common understanding of the requirements. To be honest I’m not forcing you to change current CEPies and break the compatibility – I’m trying to adjust Runtime API to make generated code clear, straightforward and working. This process requires some support from Runtime side and I ask you for this support. For example, AFAIU suggested migration path with CanonicalEditPolicyV2 will fulfil all the requirements from your side and from our side. If you have better solution – do not hesitate to post it here.
(In reply to comment #13) > >I think we have a miscommunication here. In the conference call I said > >that Canonical edit policies had been designed to synchronize semantic elements > >(EObjects) with Views, this is not an opinion it is a fact. I'm not saying > >it is the best but this is what we have today > Sure I see it. And my point is: to drive GMF project forward we have to change > assumptions used while designing CanonicalEditPolicies and modify it in > accordance. What I’m going to do is to create requirements for the > Canonical/Non-Canonical containers/diagrams on wiki to finalize it. > >I did not say that I¡¦ll close this request, because I think there is a > >value in supporting that with only one condition, we have to make sure > >that adding this support will not affect existing clients when it comes > >to performance or memory consumption ( I mean the temporary memory > >consumption during the refresh), which I think is achievable by a > >sub classed canonical edit policy > 1. Do not think old clients will have any additional performance or memory > problems if we will change API in a compatible way, but corresponding methods > will not be implemented on their side.. > 2. We always receive the answer “it is not possible due to the legacy code”.. > In this particular case I do not see any problems on introducing completely new > CanonicalEditPolicy into Runtime, mark old one as “deprecated” and later on > remove old classes from API. What do you think about this solution? I can > create a patch for you. > >reply I did not get some of them for example you talked about adding > >listeners and removing them if I¡¦m doing a canonical refresh why would I need > Yes, that was my mistake – EditPart of source node of the link (responsible for > canonical link refresh) is listening for semantic source node, but I have to > copy-paste the logic of shouldHandleNotificationEvent() at least the part > selecting correct features of underlying domain model element and triggering > update if necessary. > >element, also regarding refresh on activating does not the edit part refresh > >any way on activating as well > Yes, it does. > >So, to make the long story short, I agree we need to add this support and i did > >not plan to close the request but it will be lower priority with respect to the > >other canonical edit polices issues. > In this case I do not understand why you while realizing all these facts > suggest me to place corresponding logic into > EditPart.refreshSource/TargetConnections() during the teleconference.. It looks > strange for me. ;-) > Concerning the priorities – I will not say that this request has lower > priorities then all the rest – we have Ecore diagram example generated (most > used example I hope) and this example works with synchronized diagram + > reference-based links. Once more, this problem was corrected on generator side > by generating additional logic to the CanonicalConnectionEditPolicy, but I do > not think this is a good way to work with Runtime part.. > So, to make it short: I will insist on fixing all the mentioned > problems with CanonicalEditPolicies all together. My opinion is: we will > introduce huge number of unnecessary code leading us to the unclear API and > adding garbage to the open-source code if we will fix all CanonicalEditPolicies > problems without total refactoring of corresponding classes. If you think this > is impossible due to the compatibility problems with legacy code I suggest to > create new CanonicalEditPolicyV2 and CanonicalConnectionEditPolicyV2 in the > runtime and mark old classes as deprecated. Another option is to develop > different updating mechanism and use it throughout GMF. I think use cases I > will create on wiki will help us to get common understanding of the > requirements. > To be honest I’m not forcing you to change current CEPies and break the > compatibility – I’m trying to adjust Runtime API to make generated code clear, > straightforward and working. This process requires some support from Runtime > side and I ask you for this support. For example, AFAIU suggested migration > path with CanonicalEditPolicyV2 will fulfil all the requirements from your side > and from our side. If you have better solution – do not hesitate to post it > here. Alex; I'm starting to get the feeling that we are going in loops here. You say “We always receive the answer “it is not possible due to the legacy code” I did not say that in my reply, i did not say it is not possible to do and I have no clue where did you get that impression from. All what i said we had to make sure the change will not affect existing clients of GMF, Since there are released products in market now that are based on GMF 1.0, and i do not think this is something bad to say :) When i read your reply the only thing i see that we do not agree on is the priority, you are saying it is high priority and i'm saying it is not Thank you for suggesting how can I do it :), but I think have a rough idea in mind on how to introduce this in a nice way without deprecating any thing or affecting the performance/memory You could have saved your self time by just saying "I think this is important request, and it should be high priority :) " Since you are saying it is important for you, I’ll consider it when I (or someone in my team) start working on the canonical edit policy refactoring One more try to make sure my message will get through this time (In a point list format since Alex like it): 1- I agree we need to do this change 2- I never said it is not doable 3- I never mentioned the word Legacy code, i just stated the current design constrains in the canonical edit policy, :) 4- I thought it is not a high priority (and still think so, it can be accomplished in many ways for example canonical refresh of by a ShowHideRelationShipRequest), but since the code generation side think it is high priority we will consider it while working on refactoring the canonical refresh (but this is constrained by the amount of time we have) I hope this reply is clear enough, my apology if it is not
It's clear, thanks. I would like ask you to estimate the timeframe for it.
too many things to do in this iteration, any help will be appricated
What is the timeframe for this item ? I used CannonicalConnectionEditPolicy in my editor and would like to see if I can help out.
(In reply to comment #17) > What is the timeframe for this item ? I used CannonicalConnectionEditPolicy in > my editor and would like to see if I can help out. Any help will be appreciated at any time, it will be perfect if we can close on that before the end of M7, Also we I request help on other Canonical Edit policies issues as well. So you can hold on for like a Day or so and review the list of canonical issues where we need help Thanks a lot for considering helping the GMF runtime team
(In reply to comment #16) I can create a patch dealing with LinkDescriptor, but compatible with old API.
(In reply to comment #19) > (In reply to comment #16) > I can create a patch dealing with LinkDescriptor, but compatible with old API. sure we appricate any help, we are really overloaded ont he runtime side in this iteration specially that we are trying to finish the Grouping support, Layout enhancments and notation meta model enhancment Your skill will be apprictaed on the other canonical edi tpolicies issues as well, which i think might be higher priority than this one any way, i'll update all them today and you are more than welcome to fix any of them Thanks Alex and Li for your help
move to inbox
Not yet assigned to a release (assigned to a milestone with the Plan keyword). Moving to the next release, GMF 2.1.
[GMF Restructure] Bug 319140 : product GMF and component Runtime was the original product and component for this bug
