Community
Participate
Working Groups
Currently it is nearly impossible to determine which gmfgen model element was used as a "metaelement" for an instance of notation model Node, but wee should provide this information to: - return correct EditPart class for an existing Node (in EditPartFactory) - create correct compartments/labels (in ViewProvider) I suggest storing visualID of the "metaNode" from the gmfgen model as an annotation for the created notation model Node. As a result, both highlighted problems will be solved.
Created attachment 29164 [details] Implementation of the required functionality
Created attachment 29165 [details] Implementation of the required functionality
Created attachment 29166 [details] Implementation of the required functionality
Created attachment 29167 [details] Implementation of the required functionality
Created attachment 29168 [details] Implementation of the required functionality
Notation model elements are created by ViewFactory class returned from ViewProvider. So, we are setting VisualIDs for newly created nodes in the generated ViewProvider subclasses. As a result, once user create diagram element using UI, ViewFactory will be called and newly created Node will be provided with correct value of VisualID. In case the underlying domain model was changed outside the UI (in generated EMF editor for this model) notation model structure will be updated on diagram openning (or from the refresh action): Each EditPart for the diagram node which could contains other diagram nodes bound with the domain model element has "CanonicalEditPolicy" installed. This edit pocily is responsible (will be called by runtime code) for refreshing child elements of the current notation model element. I.e. - this edit policy will be asked for an underlying domain model children - returned child domain model elements will be matched with existing notation model children of this node. As a result, not matched notation model elements will be removed, new notation model elements will be created for domain model elements without matched notation model elements. For now this matching is performed by comparing domain model element with the one stored in notation model. This is not enought for correct matching - to perform full update correctly we have to use code similar to ViewFactory for the matching process. As a result, CanonicalEditPolicy (or CanonicalConnectionEditPolicy) will be responsible for removing notation model elements with incorrect VisualID and creating new one if underlying domain model was changed outside GMF. In case of creation new diagram file, InitDiagramAction is responsible for creating and setting correct VisualID for the notation model elements. Probably, this code will reuse ViewFactory code.
Reviewed and committed. Tests were updated.
[GMF Restructure] Bug 319140 : product GMF and component Generation was the original product and component for this bug
