| shouldDeleteView in CanonicalEditPolicy [message #109595] |
Wed, 07 March 2007 10:46  |
Eclipse User |
|
|
|
Hi,
the generated method for shouldDeleteView in the CanonicalEditPolicy
looks like this:
protected boolean shouldDeleteView(View view) {
return view.isSetElement() && view.getElement() != null
// && view.getElement().eIsProxy();
}
This does not work for me, in the case when I delete a semantic model
element from a different view than the diagram. I can solve it by simply
changed the condition above to return true in any case. But I guess this
introduces some other problem. What is the rationale of the generated
code? And is my use case a bug in the current version of the generated code?
Cheers,
Steffen
|
|
|
|
|
|
|
| Re: shouldDeleteView in CanonicalEditPolicy [message #110466 is a reply to message #110451] |
Thu, 08 March 2007 17:07  |
| Eclipse User |
|
|
|
Hi Alex;
lex Shatalin wrote:
> Hello Mohammed,
>
>> I do not think that saying "in general as a workaround you can return
>> true" , is correct, does not that mean that if i drop a note inside
>> this edit part that owns this editpolicy, the very next time this edit
>> part refresh it will delete the note ?
> Not sore the diagram of this customer contains notes or other design
Exactly, that is why i did not like the statement "in general ... ".
Based on what i noticed in the last few days; it looks like the
canonical edit policy some times is used to do an edit helper job, which
is bad and was never the intent behind the design of the edit policy.
May be what we are missing is an article on the WIKI explaining what is
the job of a canonical edit policy and few tips on what is recommended
and what is not.
I'll try to work on that as soon I'm back from vacation, so hopefully
there will ba an article by mid or April
> elements. In any case, references request AFAIR contains a lot of
> information about this method, so it could be used for implementing
> correct logic inside this method.
Of course, i agree with you 100% there is no way the code generation or
the runtime will be able to implement the shouldDeleteView in a way that
will cover all use cases. I think the article might help users to decide
is they need to modify the shouldDeleteView method or if they just need
an edit helper and so on ...
>
> -----------------
> Alex Shatalin
>
>
|
|
|
|
| Re: shouldDeleteView in CanonicalEditPolicy [message #111708 is a reply to message #110451] |
Wed, 14 March 2007 02:02 |
| Eclipse User |
|
|
|
Alex Shatalin schrieb:
> Hello Mohammed,
>
>> I do not think that saying "in general as a workaround you can return
>> true" , is correct, does not that mean that if i drop a note inside
>> this edit part that owns this editpolicy, the very next time this edit
>> part refresh it will delete the note ?
> Not sore the diagram of this customer contains notes or other design
> elements. In any case, references request AFAIR contains a lot of
> information about this method, so it could be used for implementing
> correct logic inside this method.
Hi,
indeed for my use case returning true is a valid workaround. But I very
much like the solution presented in bugzilla of checking modelID and
visualID. This really seems to be a good thing in general... I would opt
for making this the default :-)
Cheers and many thanks for all the extensive comments on this issue...
Steffen
|
|
|
Powered by
FUDForum. Page generated in 0.09577 seconds
Home