| Generated diagram edit policy discards most of the semantic edit command [message #1386211] |
Sat, 14 June 2014 22:59  |
|
Hi, Team,
(Luna RC4)
I am having trouble with edit commands provided by Papyrus's UML
element-type "edit helpers". Specifically, the edit helpers are
providing the correct commands, but then the generated semantic edit
policies in the diagrams discard most of the command, so that in fact
what is left doesn't actually do the edit that was originally requested
(only a couple of advice commands that don't make sense without the
principal edit behaviour).
The particular case is destruction of an element. I have a solution
for bug 431618 [1] in which I have created an edit-helper advice that
provides commands that delete problem markers associated with an
element that is being deleted from the model (and restore the markers
on undo). This works fine, but it seems to be exposing a latent bug in
the generated semantic edit policies in the Deployment diagram and
others. This shows up as test failures.
For example, TestDeploymentDiagramTopNode::testToManageIPackage() fails
in the step that deletes a package because the command that is
requested to delete the package doesn't actually delete it at all. It
does a couple of ancillary tweaks provided by advice, but it doesn't
delete the package. The code depicted below in the
PackageItemSemanticEditPolicy takes a perfectly good deletion command
provided by the edit helper and discards it, replacing it with another
command that doesn't get the job done:
1. The incoming 'editPolicyCommand' is a fully functional composite
command that deletes the package, markers attached to it, and the
contents of the package and markers attached every contained element
(recursively).
2. The 'editPolicyCommand' is stuffed into some request parameter that
I don't know what it means or how it is supposed to be used.
3. Then, a new request to get a delete command is sent to some other
edit-helper that is not like the one that originally provided the real
deletion command (this is a generated edit-helper for some nameless
"visual ID" specialization type (as it happens,
org.eclipse.papyrus.uml.diagram.deployment.Package_2009). Whatever
this edit helper was expected to do with the 'editPolicyCommand'
supplied as a request parameter, it doesn't do it because ...
4. ... the resulting command that ends up being returned has none of
the deletion behaviour from the original 'editPolicyCommand' but only
some advice that doesn't make sense when the core deletion is not being
done.
I have no idea why this is so complicated, why there are two requests
to different edit helpers to get deletion commands, and one of them
(the important one) ends up being completely discarded.
All that I have done is to register a new edit-helper advice that
provides commands that work with problem markers, not model content.
As such, they are not "transactional commands" but the GMF Run-time and
EMF Transaction API that it's built on have supported that fine for
most of a decade. Any ideas what is going wrong, here? I'm not
figuring it out ...
Thanks,
Christian
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=431618
|
|
|
|
| Re: Generated diagram edit policy discards most of the semantic edit command [message #1386215 is a reply to message #1386212] |
Sun, 15 June 2014 00:24  |
|
OK, so I know why the problem is happening. What I'm not so sure of is
whether it makes sense.
So, the problem is that the visual element type in question
(Package_2009) is a specialization of GMF's "null element type":
org.eclipse.gmf.runtime.emf.type.core.null. There are 66 of such
visual element types in the Papyrus diagram plug-ins that specialize
the null element type, e.g.:
Some of these are INotationTypes, for which it makes sense because they
aren't a visualization of any semantics. But for those like the
Package_2009 depicted above, some visualization of a package in a
deployment-diagram context, it doesn't make sense to me that they
should not be specializations of the UML Package element type.
Anyways, because the null element type's edit helper doesn't know to
look in the request for the "edit policy command" request parameter
that provides the "instead command" (the null edit helper always
provides a null instead command), it doesn't actually wrap the real
semantic command in the advice bound to the visual element type.
In my case, my advice does provide a command to the visual element type
(it is applicable for all elements of every kind), so we end up losing
the semantic command and only getting a bit of advice.
I can work around this by having my advice provide a command only when
this visual-edit-helper delegation pattern is not happening, by
checking whether the "edit policy command" request parameter is
present. That fixes my problem.
However, I am concerned about what looks like a dubious use of the null
element type in our diagrams. Should I raise a bug about that?
Thanks,
Christian
|
|
|
Powered by
FUDForum. Page generated in 0.02610 seconds
] 
Search
Help
Register
Login
Home
