Community
Participate
Working Groups
Build Identifier: 20110615-0604 When the mapping model contains phantom nodes, the refreshSemantic method of the XXXCanonicalEditPolicy contain compilation errors right after generation. getXXX_YYYSemanticChildren methods are called which don't exist. Reproducible: Always Steps to Reproduce: 1. Create an EMF metamodel with a root for a model, elements (A) contained in that root, and elements (B) contained in these elements. 2. Create corresponding gmfmap and gmftool models (as simple as possible) 3. Create a gmfmap model containing phantom nodes: - the root as canvas - A as top level nodes - B as top level nodes, but no "containment feature" set (phantom nodes) 4. create the gmfgen model 5. generate the diagram code. The xxx.diagram plugin project contains compilation errors. I can provide you an example project that I developped as an example. Don't hesitate to contact me if you're interested.
Created attachment 199784 [details] Phantom node bug example project Here is an example project that should reproduce the bug. All you have to do to generate the bug is to import the project, generate the edit and editor from the gmfgen file contained in the "model" folder, and then generate the diagram plugin from the "diagrams" folder.
The problem is that the DiagramUpdater#getXXXSemanticChildren method is guarded by the qvto filter (DiagramUpdater.xpt, line 27) hasSemanticChildren(), while the presence of the XXXCanonicalEditPolicy that always contains the call to this method is guarded by the java check GenChildContainer#needsCanonicalEditPolicy. The latter is implemented as if (!isSansDomain() && getDiagram().isSynchronized()) { return !getContainedNodes().isEmpty() || (getDiagram().getGenClass2PhantomMap().size() > 0 && getDiagram().getPhantomLinks().size() > 0); which is always true for diagrams with phantoms. Its seems a bit too risky to fix this by changing the guards itself, or by adding the getXXXSemanticChildren methods into the Updater generated code, so I tend to add the concrete check from the updater guard into the impl::diagram::update::CanonicalUpdate#refreshSemanticChildren template.
Although it seems that the whole refreshSemanticChildren method is not needed in case if hasSemanticChildren(genNode) == false, I am not brave enough to remove it right now. So in 2.4(.1) we will have the same long code generated into the CanonicalEditPolicy, except that it will operate on the List<XXXNodeDescriptor> childDescriptors = Collections.emptyList();
Temporrary workaround committed, the whole bug to be revisited in next release (with respect to #352288)
