| boolean return value of canCreate / canMove etc. [message #725607] |
Thu, 15 September 2011 10:48  |
 Andreas Graf
Messages: 211
Registered: July 2009 |
Senior Member |
|
|
Dear all,
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?
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?
Andreas
[Updated on: Thu, 15 September 2011 10:49] Report message to a moderator |
|
|
|
| Re: boolean return value of canCreate / canMove etc. [message #725663 is a reply to message #725607] |
Thu, 15 September 2011 13:40  |
Michael Wenz
Messages: 1921
Registered: July 2009
Location: Walldorf, Germany |
Senior Member |
|
|
Returning a reason why something cannot be moved sounds really useful. Would
you open an enhancement Bugzilla for that?
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).
Michael
"Andreas Graf" schrieb im Newsbeitrag news:j4skg4$qj3$1@news.eclipse.org...
Dear all,
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?
Andreas
|
|
|
Powered by
FUDForum. Page generated in 0.01741 seconds
Search
Help
Register
Login
Home
