Skip to main content



      Home
Home » Modeling » Graphiti » boolean return value of canCreate / canMove etc.
boolean return value of canCreate / canMove etc. [message #725607] Thu, 15 September 2011 06:48 Go to next message
Eclipse UserFriend
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 06:49] by Moderator

Re: boolean return value of canCreate / canMove etc. [message #725617 is a reply to message #725607] Thu, 15 September 2011 07:05 Go to previous messageGo to next message
Eclipse UserFriend
Andreas,

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.

Jos
Re: boolean return value of canCreate / canMove etc. [message #725663 is a reply to message #725607] Thu, 15 September 2011 09:40 Go to previous message
Eclipse UserFriend
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
Previous Topic:Scrolling / zooming programmatically
Next Topic:where to add model listeners to refresh property view
Goto Forum:
  


Current Time: Tue Jul 01 13:26:07 EDT 2025

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

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

Back to the top