Home » Modeling » GMF (Graphical Modeling Framework) » Validation, Dangling Edges and EMF-View
Validation, Dangling Edges and EMF-View [message #60587] |
Mon, 09 October 2006 11:02 |
Eclipse User |
|
|
|
Originally posted by: tobk.gmx.de
Hello,
I have some more questions and I'd be happy if anyone could help me.
1.: Is there an advantage in using OCL for describing validaition
constraints instead of java making it the default option? I can't imagine
it being faster, since it has to be parsed and interpreted first, and
everybody using Eclipse hould know Java, but not everybody knows OCL (like
me). Further, the Java constraints can be modified in Debug mode while the
OCl constraint might require several generation runs for debigging. I'd
just like to know if there's any big plus for OCL that I'm missing.
2.: What method do I have to tweak so that all of a node's edges are deleted
with the node? Right now, only the node is deleted. The connections are
removed from the diagram, but not from the model (if the node contains the
connection, the connection is deleted too, but the references on the
connection, e.g. from the target remain). I searched the web, but did not
find an answer yet. Could you tell me what to do or give me a reference?
3.: I posted a similar question some time ago. Is three a way to integrate
the generated EMF-Editor as an extra view or - even better - as additional
pages for the main view (like "Diagram | Selection | Parent | List | ..."?
Thanks,
Tobias
|
|
|
Re: Validation, Dangling Edges and EMF-View [message #60625 is a reply to message #60587] |
Tue, 10 October 2006 13:42 |
Eclipse User |
|
|
|
Originally posted by: vcciubot.uwaterloo.ca
> 2.: What method do I have to tweak so that all of a node's edges are deleted
> with the node? Right now, only the node is deleted. The connections are
> removed from the diagram, but not from the model (if the node contains the
> connection, the connection is deleted too, but the references on the
> connection, e.g. from the target remain). I searched the web, but did not
> find an answer yet. Could you tell me what to do or give me a reference?
>
public abstract class EndEditHelper extends AbstractEditHelper {
/**
* Gets a command to destroy the connections incident to this block
*/
protected ICommand getDestroyDependentsCommand(DestroyDependentsRequest request) {
End end = (End) request.getElementToDestroy();
Set ret = new HashSet();
ret.addAll(end.getOutgoingConnections());
ret.addAll(end.getIncomingConnections());
return request.getDestroyDependentsCommand(ret);
}
....
}
|
|
|
Re: Validation, Dangling Edges and EMF-View [message #62170 is a reply to message #60625] |
Fri, 13 October 2006 13:10 |
Eclipse User |
|
|
|
Originally posted by: tobk.gmx.de
Vlad Ciubotariu wrote:
>> 2.: What method do I have to tweak so that all of a node's edges are
>> deleted with the node? Right now, only the node is deleted. The
>> connections are removed from the diagram, but not from the model (if the
>> node contains the connection, the connection is deleted too, but the
>> references on the connection, e.g. from the target remain). I searched
>> the web, but did not find an answer yet. Could you tell me what to do or
>> give me a reference?
>>
>
> public abstract class EndEditHelper extends AbstractEditHelper {
> ....
> }
Thank you for the reply, but somehow I don't get this to work. The method is
not even called when I delete the node (yes, I put it in the right edit
helper. that was my first thought, but I checked it ten times now ;-) ).
And even more strange: The method is called in the AbstractEditHelper
class, but neither in the actual NodeEditHelper nor in the BaseEditHelper
classes, both extending the abstractedithelper.
I also tried putting the method in another EditHelper that's already used
with another getCommand method (getReorientConnectionCommand), but even
there the overriding method is not called, but only the one in the abstract
edit helper. I copied the method signatures, so I can exclude a spelling
mistake, too.
tobias
|
|
|
Re: Validation, Dangling Edges and EMF-View [message #62265 is a reply to message #62170] |
Fri, 13 October 2006 15:39 |
Eclipse User |
|
|
|
Originally posted by: vcciubot.uwaterloo.ca
If I remember correctly, the generated edit helpers have a base class that
overrides getInsteadCommand() that does the actual routing of a Request to
the the corresponding method call.
Please check that to see if that's what's breaking things.
vlad
On Fri, 13 Oct 2006 15:10:55 +0200, tobias wrote:
> Vlad Ciubotariu wrote:
>
>>> 2.: What method do I have to tweak so that all of a node's edges are
>>> deleted with the node? Right now, only the node is deleted. The
>>> connections are removed from the diagram, but not from the model (if the
>>> node contains the connection, the connection is deleted too, but the
>>> references on the connection, e.g. from the target remain). I searched
>>> the web, but did not find an answer yet. Could you tell me what to do or
>>> give me a reference?
>>>
>>
>> public abstract class EndEditHelper extends AbstractEditHelper {
>> ....
>> }
>
> Thank you for the reply, but somehow I don't get this to work. The method is
> not even called when I delete the node (yes, I put it in the right edit
> helper. that was my first thought, but I checked it ten times now ;-) ).
> And even more strange: The method is called in the AbstractEditHelper
> class, but neither in the actual NodeEditHelper nor in the BaseEditHelper
> classes, both extending the abstractedithelper.
>
> I also tried putting the method in another EditHelper that's already used
> with another getCommand method (getReorientConnectionCommand), but even
> there the overriding method is not called, but only the one in the abstract
> edit helper. I copied the method signatures, so I can exclude a spelling
> mistake, too.
>
> tobias
|
|
|
Re: Validation, Dangling Edges and EMF-View [message #62383 is a reply to message #62265] |
Sat, 14 October 2006 10:43 |
Eclipse User |
|
|
|
Originally posted by: tobk.gmx.de
Vlad Ciubotariu wrote:
> If I remember correctly, the generated edit helpers have a base class that
> overrides getInsteadCommand() that does the actual routing of a Request to
> the the corresponding method call.
>
> Please check that to see if that's what's breaking things.
That's right, but this method only collects the corresponding commands from
the edit policy and the edit helper (invoking the super method) and returns
them (only one, if the other is null or via a compound command).
Meanwhile I really think that the actual EditHelper is not associated
correctly with the EditPart: I placed an overriding getInsteadCommand in
the EditHelper, returning the required command and else the super method's
results, but debugging says that it is not used, but only the
baseEditHelper's! Instead, it is used when selecting a connection next to
that node, and the connections getInsteadCommand is not entered, but when I
try to reorient the Connection. How can this be? Is this normal behavior?
In case this was a little bit confusing:
- I have some Nodes and Connections
- both EditHelpers override getInsteadCommand, with a breakpoint inside and
calling the super method, just to see when it's called
- when I select or delete the node, the BaseEditHelper's getinsteadCommand
is called, but not the actual node's EditHelper's.
- when I select or delete a *connection* connected to the node, the *node*'s
EditHelper's getInsteadCommand is called (with a destroy request)
- when I try to reorient the connection, the connection's helper's
getInsteadCommand is called
tobias
|
|
|
Re: Validation, Dangling Edges and EMF-View [message #62800 is a reply to message #62383] |
Sun, 15 October 2006 17:28 |
Eclipse User |
|
|
|
Originally posted by: vcciubot.uwaterloo.ca
Hi Tobias,
Export those plugins to a zip file and send them to me.
cheers
vlad
On Sat, 14 Oct 2006 12:43:31 +0200, tobias wrote:
> Vlad Ciubotariu wrote:
>
>> If I remember correctly, the generated edit helpers have a base class that
>> overrides getInsteadCommand() that does the actual routing of a Request to
>> the the corresponding method call.
>>
>> Please check that to see if that's what's breaking things.
>
> That's right, but this method only collects the corresponding commands from
> the edit policy and the edit helper (invoking the super method) and returns
> them (only one, if the other is null or via a compound command).
>
> Meanwhile I really think that the actual EditHelper is not associated
> correctly with the EditPart: I placed an overriding getInsteadCommand in
> the EditHelper, returning the required command and else the super method's
> results, but debugging says that it is not used, but only the
> baseEditHelper's! Instead, it is used when selecting a connection next to
> that node, and the connections getInsteadCommand is not entered, but when I
> try to reorient the Connection. How can this be? Is this normal behavior?
>
> In case this was a little bit confusing:
> - I have some Nodes and Connections
> - both EditHelpers override getInsteadCommand, with a breakpoint inside and
> calling the super method, just to see when it's called
>
> - when I select or delete the node, the BaseEditHelper's getinsteadCommand
> is called, but not the actual node's EditHelper's.
> - when I select or delete a *connection* connected to the node, the *node*'s
> EditHelper's getInsteadCommand is called (with a destroy request)
> - when I try to reorient the connection, the connection's helper's
> getInsteadCommand is called
>
> tobias
|
|
|
Re: Validation, Dangling Edges and EMF-View [message #64156 is a reply to message #62800] |
Tue, 17 October 2006 13:56 |
Eclipse User |
|
|
|
Originally posted by: tobk.gmx.de
Vlad Ciubotariu wrote:
> Hi Tobias,
>
> Export those plugins to a zip file and send them to me.
>
> cheers
> vlad
Thanks for the offer, but the problem seems to be solved in the GMF 2.0
Stream Stable Build. The getXXXCommand method now is entered in the correct
edit helper. However, there's still another problem:
All the incoming and outgoing connections are added to the Set of
connections to be deleted, but those connections, that are a child of the
node are not deleted.
In my model all the connections are contained in their source node. Reason
for this is that I have many levels of elements, and other than saving all
the connections in the canvas element or something like that this prevents
this nasty duplicate connections bug from happening.
Should I modify the getdeleteDependentCommand method in some way it
correctly deletes the children [1] or is there any workaround for the
duplicate connections bug? Or will this bug be fixed in the final GMF 2.0?
[1] the connections are deleted (since they are children of the node), but
not in a clean way. all references pointing on the connections persist. By
the way this applies for all kind of child references: when I delete some
model element with children being references outside of that element, these
references persist when I delete the element. Is there a reason why this is
not handled automatically?
tobias
|
|
|
Re: Validation, Dangling Edges and EMF-View [message #64432 is a reply to message #64156] |
Tue, 17 October 2006 16:15 |
Eclipse User |
|
|
|
Originally posted by: vcciubot.uwaterloo.ca
> Thanks for the offer, but the problem seems to be solved in the GMF 2.0
> Stream Stable Build. The getXXXCommand method now is entered in the correct
> edit helper. However, there's still another problem:
>
> All the incoming and outgoing connections are added to the Set of
> connections to be deleted, but those connections, that are a child of the
> node are not deleted.
getdeleteDependentCommand could delete various referenced eobjects, those
contained in the current object are automatically deleted.
This command operates solely on the model.
Delete commands are returned by the component edit policy. If your
container of the object is canonical this policy performs a semantic
delete and delegates to the canonical policy to remove the view.
>
> In my model all the connections are contained in their source node. Reason
> for this is that I have many levels of elements, and other than saving all
> the connections in the canvas element or something like that this prevents
> this nasty duplicate connections bug from happening.
There's a very simple work around for this bug: Override in
GraphicalNodeEditPolicy this command:
protected Command getConnectionAndRelationshipCompleteCommand()
Basically, copy & paste from super and comment out this line:
//cc.compose( new CommandProxy(viewCommand) );
This way the command produces only the semantic update and allows the
canonical policy to resynchronize.
>
> Should I modify the method in some way it
> correctly deletes the children [1] or is there any workaround for the
> duplicate connections bug? Or will this bug be fixed in the final GMF 2.0?
See above.
>
> [1] the connections are deleted (since they are children of the node), but
> not in a clean way. all references pointing on the connections persist. By
> the way this applies for all kind of child references: when I delete some
> model element with children being references outside of that element, these
> references persist when I delete the element. Is there a reason why this is
> not handled automatically?
Delete them explicitly from the edit helper.
|
|
|
Re: Validation, Dangling Edges and EMF-View [message #65511 is a reply to message #64432] |
Thu, 19 October 2006 09:58 |
Eclipse User |
|
|
|
Originally posted by: tobk.gmx.de
Thank you, it seems to work so far. But now there's another problem: Undo
doesn't work anymore.
Here's what I basically did:
In BaseEditHelper:
- getDestroyElementCommand returns super
- getDestroyDependantCommand returns Command if list of Dependants is not
empty and else null
Problem: Undo doesn't work anymore for delete commands.
What I've tried so far:
- let BaseEditHelpers getDestroyElementCommand return null, if the element
is not of type node -> undo is working again for deleting connections, but
connections are not deleted together with nodes anymore
- let node's edit policy's getDestroyElementCommand return null -> deleting
connections with nodes and undoing seems to work, but doing this for all
nodes seems not to be best practice
- if the Edit Helper command is not null have the BaseEditHelper
getisteadCommand return only the edit helpers command, ignoring that of the
edit policy -> doesn't work at all (why? shouldn't this have the same
effect like having all the edit policies return null?)
Do you have an idea how to fix this?
tobias
|
|
|
Re: Validation, Dangling Edges and EMF-View [message #65574 is a reply to message #65511] |
Thu, 19 October 2006 11:41 |
Eclipse User |
|
|
|
Originally posted by: tobk.gmx.de
tobias wrote:
> Thank you, it seems to work so far. But now there's another problem: Undo
> doesn't work anymore.
Ok, I think that I finally got it. Both deleting nodes with connections and
deleting connections alone executes correctly and can be undone. Here's
what I did.
(I modified only the BaseEditHelper, since I think maintaining one class
with some ifelses is easier than maintaining many similar classes.)
1.: for DetroyElementRequests the getInsteadCommand returns only the edit
helper's command, ignoring the edit policy's
2.: getDestroyCommand returns super
3.: getDestroyDependantsCommand returns super, if the list of dependants is
empty
This seems to be the easiest way. Please write back if by your opinion there
are any redundancies or unwanted side effects.
tobias
|
|
|
Re: Validation, Dangling Edges and EMF-View [message #65852 is a reply to message #65574] |
Thu, 19 October 2006 18:04 |
Eclipse User |
|
|
|
Originally posted by: vcciubot.uwaterloo.ca
> 1.: for DetroyElementRequests the getInsteadCommand returns only the edit
> helper's command, ignoring the edit policy's
>
That's basically what I have too. I've totally removed the customized
semantic policy, running with the vanilla one installed in
GraphicalEditPart. The default behaviour in that policy is to delegate
everything to the edit helper.
> 2.: getDestroyCommand returns super
same here
>
> 3.: getDestroyDependantsCommand returns super, if the list of dependants is
> empty
same here
|
|
|
Goto Forum:
Current Time: Wed Feb 05 10:45:43 GMT 2025
Powered by FUDForum. Page generated in 0.02995 seconds
|