Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » GMF (Graphical Modeling Framework) » Prohibit moving nodes into compartments
Prohibit moving nodes into compartments [message #206075] Thu, 18 September 2008 18:34 Go to next message
Thomas Beyer is currently offline Thomas BeyerFriend
Messages: 47
Registered: July 2009
Member
Dear community,

I want to prevent the user from moving nodes into compartments or from
one compartment to a different one.

My use-case is as follows:
1. my diagram consists of elements of type A and elements of type B
2. elements of type A can contain elements of type B

I created corresponding mapping models a.s.o.
-> When generating code, there are two EditParts of type B, one for the
top-level node, the other one for the compartment node A.
This means, both EditParts map to two different view-types resp. ids in
the notation-model.

The following problem occurs:
1. I create an element A and an element B top-level.
2. I can move element B into element A.

-> Problem 1: I don't want my clients to be able to move A into B. The
user shall be able to create B top-level and create B inside A, but not
to move an existing top-level B into A.
Whats the command or consistant/hierarchy check, that is invoked, when
triggering this movement?
Even though my meta-model would allow to do so, I don't want the editor
to do so.

-> Problem 2: Creating B top-level, results in the corresponding
notation-view-id 1000. Creating B into A, results in the
notation-view-id 1001 for B.
Moving B top-level into A does not update the view-ids. B still has id
1000 inside A, which should not be the case.

Any suggestions or hints are very much appreciated.


TIA
Thomas
Re: Prohibit moving nodes into compartments [message #206206 is a reply to message #206075] Mon, 22 September 2008 06:52 Go to previous messageGo to next message
Thomas Beyer is currently offline Thomas BeyerFriend
Messages: 47
Registered: July 2009
Member
> -> Problem 1: I don't want my clients to be able to move A into B. The
> user shall be able to create B top-level and create B inside A, but not
> to move an existing top-level B into A.
> Whats the command or consistant/hierarchy check, that is invoked, when
> triggering this movement?
> Even though my meta-model would allow to do so, I don't want the editor
> to do so.

I found that the generated
XXXBaseItemSemanticEditPolicy#getCommand(Request request) can be used for
this.

...
if (request instanceof EditCommandRequestWrapper){
IEditCommandRequest ier =
((EditCommandRequestWrapper)request).getEditCommandRequest() ;
if(ier instanceof MoveRequest){
MoveRequest mr = (MoveRequest)ier;
//anything can be done from here
//returning null simply doesn't allow the move command, which is the
behavior I intended
}
}
...



> -> Problem 2: Creating B top-level, results in the corresponding
> notation-view-id 1000. Creating B into A, results in the
> notation-view-id 1001 for B.
> Moving B top-level into A does not update the view-ids. B still has id
> 1000 inside A, which should not be the case.

I guess I have to chain another command to update the view and its
children to the resulting command of the method above.

I was hoping, that the GMF-Runtime would take care of this.


Regards, Thomas
Re: getReparentViewCommand [message #206999 is a reply to message #206075] Thu, 25 September 2008 09:56 Go to previous messageGo to next message
Thomas Beyer is currently offline Thomas BeyerFriend
Messages: 47
Registered: July 2009
Member
Dear contributors,


> -> Problem 2: Creating B top-level, results in the corresponding
> notation-view-id 1000. Creating B into A, results in the notation-view-id
> 1001 for B.
> Moving B top-level into A does not update the view-ids. B still has id
> 1000 inside A, which should not be the case.



I think, the problem is based on CreationEditPolicy#getReparentViewCommand:

protected ICommand getReparentViewCommand( IGraphicalEditPart gep ) {
View container = (View)getHost().getModel();
View view = (View)gep.getModel();
return new AddCommand(gep.getEditingDomain(), new
EObjectAdapter(container),
new EObjectAdapter(view));
}

If the existing view (which is the matching view for the current container)
is used in the AddCommand to create the view for the new container (and its
very much likely, that <current container> and <new container> are not of
the same type) the result explained above occurs.
For my understanding, there should be a check, whether the view fits in the
<new container> (via the ids) and if not, the correct one should be created
and passed to the AddCommand.

I'd like to ask for some feedback on this matter.



TIA & Regards
Thomas
Re: getReparentViewCommand [message #208053 is a reply to message #206999] Wed, 08 October 2008 10:07 Go to previous message
Thomas Beyer is currently offline Thomas BeyerFriend
Messages: 47
Registered: July 2009
Member
I subclassed the default CreationEditPolicy and installed it on my EditParts
to debug the method.

@Override

protected ICommand getReparentViewCommand(IGraphicalEditPart gep) {

View container = (View)getHost().getModel();

View view = (View)gep.getModel();

System.out.println(XXXVisualIDRegistry.canCreateNode(contain er,
XXXVisualIDRegistry.getVisualID(view)));

return new AddCommand(gep.getEditingDomain(), new EObjectAdapter(container),

new EObjectAdapter(view));

}

The syso always returns false, if the node is shifted from compartment of
type A to compartment of type B, where the shifted node has a different id
(type) in A as in B.
For my understanding, the CreationEditPolicy is doing something wrong here
(the false-return of canCreateNode indicates, that the subsequent AddCommand
does invalid stuff).
I'd like to support on this issue, if anyone tells me what would be the best
way to solve it.

TIA & regards
Thomas



"Thomas Beyer" <thomas.beyer@atlas-elektronik.com> schrieb im Newsbeitrag
news:gbfn9f$oqv$1@build.eclipse.org...
> Dear contributors,
>
>
>> -> Problem 2: Creating B top-level, results in the corresponding
>> notation-view-id 1000. Creating B into A, results in the notation-view-id
>> 1001 for B.
>> Moving B top-level into A does not update the view-ids. B still has id
>> 1000 inside A, which should not be the case.
>
>
>
> I think, the problem is based on
> CreationEditPolicy#getReparentViewCommand:
>
> protected ICommand getReparentViewCommand( IGraphicalEditPart gep ) {
> View container = (View)getHost().getModel();
> View view = (View)gep.getModel();
> return new AddCommand(gep.getEditingDomain(), new
> EObjectAdapter(container),
> new EObjectAdapter(view));
> }
>
> If the existing view (which is the matching view for the current
> container) is used in the AddCommand to create the view for the new
> container (and its very much likely, that <current container> and <new
> container> are not of the same type) the result explained above occurs.
> For my understanding, there should be a check, whether the view fits in
> the <new container> (via the ids) and if not, the correct one should be
> created and passed to the AddCommand.
>
> I'd like to ask for some feedback on this matter.
>
>
>
> TIA & Regards
> Thomas
>
Previous Topic:How to extend DiagramImpl?
Next Topic:[OCL] Unknown type error during validation
Goto Forum:
  


Current Time: Fri Mar 29 00:38:01 GMT 2024

Powered by FUDForum. Page generated in 0.02103 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top