Home » Modeling » GMF (Graphical Modeling Framework) » updating diagram when automatically removing transient children
| updating diagram when automatically removing transient children [message #69782] |
Thu, 26 October 2006 05:59  |
Eclipse User |
|
|
|
Originally posted by: evenjn.gmail.com
Hi,
I'm having trouble in getting the children of an entity be removed
automatically: my purpose is to add and remove _transient_ children of
an entity when changing an unrelated attribute, such as the name of the
entity.
The solution I adopted is to modify the setName() method in the
EMF-generated impl class, adding the proper eSet calls.
The result is, when editing a diagram with the generated editor,
changing the name of such an entity triggers an update in the children
list adding figures for newly-added children, but *not removing* figures
for the just-removed children, which have been semantically removed, but
not graphically.
Closing and re-opening the diagram results in the removal of the orphan
figures.
As an aside, before choosing this way I tried to accomplish the task by
editing the EMF-generated provider class for the entity, overriding the
createCommand method.
Although this way the diagram behaved correctly (adding/removing
children reflecting the result of the execution the command - which does
not directly address gmf classes!), there was an other problem: when a
diagram file was opened using the editor, gmf did not set up the entity
using a provider, so transient children were not created.
Regards,
Marco Trevisan
|
|
| |
| Re: updating diagram when automatically removing transient children [message #70070 is a reply to message #69929] |
Thu, 26 October 2006 08:30  |
| Eclipse User |
|
|
|
Originally posted by: evenjn.gmail.com
I have solved my problem, and I have an other little question.
A short explanation follows, while the question is at the end.
Alex Shatalin wrote:
> Hello Marco,
>
> Generated ???CanonicalEditPolicy is responsible for adding/removing
> visual elements on any changes in underlying domain model. Looks like
> it works incorrectly in this situation. Can you please debug it to
> find the reason (put a breakpoint into getSemanticChildrenList()
> method and see what's happening on renaming an entity)?
> As a workaround you can call ???CanonicalEditPolicy.refresh() the the
> corresponding changes will be applied.
> -----------------
> Alex Shatalin
I already tried the workaround, anyway the refresh() was called at the
right point.
I solved also thanks to the following advice by Mohammed Mostafa:
> news://new.eclipse.org:119/ebatsj$1v1$1@utils.eclipse.org
>
> Re: Remove events are ignored
>
> HI;
> The Remove events are not ignored, they are handled already and
> being forwarded by the DiagramEventBroker to the listeners
> Add a break point to the notifychanged method on the canonical edit
> policy, and check if this break point hits when you delete your semantic
> element. This might give us some clues.
> What we need to check: is refresh being called on your edit policy or not?
> and if it is called is it deleting the views when you delete the semantic
> elements or not
Anyway, debugging I found that the CanonicalEditPolicy
refreshSemanticChildren(..) method was eventually called, and within
this call some orphans were collected in order to be deleted.
The subsequent call to deleteViews(..) over the orphans appeared to
"forget" to delete those nodes, but this was because shouldDeleteView in
the ???CanonicalEditPolicy was overriding the "return true" of the base
CanonicalEditPolicy class.
At this point my question is why does the generated
???CanonicalEditPolicy # shouldDeleteView(..) works as follows?
return view.isSetElement() && view.getElement() != null
&& view.getElement().eIsProxy();
The semantic element I deleted was not a proxy, therefore
did not allow the node to be deleted. Is there a reason for this
behavior or is this an arbitrary design choice? I am worried about the
possible implications.
Thanks for your help, Alex.
|
|
| |
| Re: updating diagram when automatically removing transient children [message #70232 is a reply to message #70070] |
Thu, 26 October 2006 10:18 |
| Eclipse User |
|
|
|
Hi Marco ;
The Fact that should Delete View is overridden in some cases is
actually done on purpose and it is not arbitrary
To Explain; consider the case where you have a canonical container that
can contain both canonical and non canonical views for example the
diagram surface can display both canonical views, and Notes (keep in
mind notes had no semantic elements, so note views will be considered
orphaned). If should delete view returns true always, then when your
container is refreshed it will delete all notes on it (actually it will
delete any view that had no semantic element)
You can always override this method and make it return true in your
specific case, I would not recommend return true always
for an example of a container that can contain canonical and non
canonical views, check the circuit compartment in the GMF Logic example,
where this compartment is canonical when is comes to LED's, but it can
contains Notes as well
> I have solved my problem, and I have an other little question.
> A short explanation follows, while the question is at the end.
>
> Alex Shatalin wrote:
>> Hello Marco,
>>
>> Generated ???CanonicalEditPolicy is responsible for adding/removing
>> visual elements on any changes in underlying domain model. Looks like
>> it works incorrectly in this situation. Can you please debug it to
>> find the reason (put a breakpoint into getSemanticChildrenList()
>> method and see what's happening on renaming an entity)?
>> As a workaround you can call ???CanonicalEditPolicy.refresh() the the
>> corresponding changes will be applied.
>> -----------------
>> Alex Shatalin
>
> I already tried the workaround, anyway the refresh() was called at the
> right point.
>
> I solved also thanks to the following advice by Mohammed Mostafa:
>
>> news://new.eclipse.org:119/ebatsj$1v1$1@utils.eclipse.org
>>
>> Re: Remove events are ignored
>>
>> HI;
>> The Remove events are not ignored, they are handled already and
>> being forwarded by the DiagramEventBroker to the listeners
>> Add a break point to the notifychanged method on the canonical edit
>> policy, and check if this break point hits when you delete your semantic
>> element. This might give us some clues.
>> What we need to check: is refresh being called on your edit policy or not?
>> and if it is called is it deleting the views when you delete the semantic
>> elements or not
>
> Anyway, debugging I found that the CanonicalEditPolicy
> refreshSemanticChildren(..) method was eventually called, and within
> this call some orphans were collected in order to be deleted.
>
> The subsequent call to deleteViews(..) over the orphans appeared to
> "forget" to delete those nodes, but this was because shouldDeleteView in
> the ???CanonicalEditPolicy was overriding the "return true" of the base
> CanonicalEditPolicy class.
>
> At this point my question is why does the generated
> ???CanonicalEditPolicy # shouldDeleteView(..) works as follows?
>
> return view.isSetElement() && view.getElement() != null
> && view.getElement().eIsProxy();
>
> The semantic element I deleted was not a proxy, therefore
> did not allow the node to be deleted. Is there a reason for this
> behavior or is this an arbitrary design choice? I am worried about the
> possible implications.
>
> Thanks for your help, Alex.
|
|
|
| Re: updating diagram when automatically removing transient children [message #70734 is a reply to message #70232] |
Fri, 27 October 2006 08:05 |
| Eclipse User |
|
|
|
Originally posted by: evenjn.gmail.com
Mohammed Mostafa wrote:
> Hi Marco ;
>
> The Fact that should Delete View is overridden in some cases is
> actually done on purpose and it is not arbitrary
> To Explain; consider the case where you have a canonical container
> that can contain both canonical and non canonical views for example the
> diagram surface can display both canonical views, and Notes (keep in
> mind notes had no semantic elements, so note views will be considered
> orphaned). If should delete view returns true always, then when your
> container is refreshed it will delete all notes on it (actually it will
> delete any view that had no semantic element)
>
> You can always override this method and make it return true in your
> specific case, I would not recommend return true always
>
> for an example of a container that can contain canonical and non
> canonical views, check the circuit compartment in the GMF Logic example,
> where this compartment is canonical when is comes to LED's, but it can
> contains Notes as well
>
>
Thank you for your rationale.
|
|
|
Goto Forum:
Current Time: Thu Jul 24 04:19:27 EDT 2025
Powered by FUDForum. Page generated in 0.05781 seconds |
Home