boolean return value of canCreate / canMove etc.https://www.eclipse.org/forums/index.php/mv/msg/240195/725607/#msg_725607
I was wondering about your opinions on the boolean return value of e.g. canMove. Right now, if it returns a false value, the cursor shows the "not possible" sign.

However, there are many context-specific reasons why a move that would otherwise be possible could fail.

E.g. Consider a UML package P1 which has a class A. Moving a class B from another package P2 to A would be fine, however, moving A from P2 to P1 might result in a naming conflict. It would be nice to inform the user why the moving is impossible.

Right now I have a prototype workaroun that shows a Popup dialog with the error message.

Would it make sense for Graphiti to change the return value of those functions to an IReason and provide some means to display that, as for drag and drop?

That seems to create a lot of new MoveFeatures (basically at every mouse move). Would it make sense to implement the getMoveShapeFeature in a way, so that you create them once and then return the same instance of MoveFeature?

Andreas
]]>Andreas Graf2011-09-15T10:48:19-00:00Re: boolean return value of canCreate / canMove etc.https://www.eclipse.org/forums/index.php/mv/msg/240195/725617/#msg_725617
I have the same experience with the move feature returning false. Sometimes users simply do not know why it isn't possible. I think it makes perfect sense to let the canMove(0 return an IReason which can be used as feedback to the user.

To you 2. question: that's true, on the other hand we haven't seen any
performance issues with that. Moving around the shape on the screen is less
slower and probably creates more new classes than this small overhead. Of
course what you propose would be an optimization you can surely implement in
your tool. What you should keep in mind is that features should be stateless
(actually they should always be, but doing that you really need that).

I was wondering about your opinions on the boolean return value of e.g.
canMove. Right now, if it returns a false value, the cursor shows the "not
possible" sign.

However, there are many context-specific reasons why a move that would
otherwise be possible could fail.

E.g. Consider a UML package P1 which has a class A. Moving a class B from
another package P2 to A would be fine, however, moving A from P2 to P1 might
result in a naming conflict. It would be nice to inform the user why the
moving is impossible.

Right now I have a prototype showing a Popup dialogue.

Would it make sense for Graphiti to change the return value of those
functions to an IReason and provide some means to display that, as for drag
and drop?

As a 2nd question, the tutorial has the following code:
public IMoveShapeFeature getMoveShapeFeature(IMoveShapeContext context) {

Shape shape = context.getShape();

Object bo = getBusinessObjectForPictogramElement(shape);

if (bo instanceof EClass) {

return new TutorialMoveEClassFeature(this);

}

return super.getMoveShapeFeature(context);

}

That seems to create a lot of new MoveFeatures (basically at every mouse
move). Would it make sense to implement the getMoveShapeFeature in a way, so
that you create them once and then return the same instance of MoveFeature?