Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Graphiti » boolean return value of canCreate / canMove etc.
boolean return value of canCreate / canMove etc. [message #725607] Thu, 15 September 2011 10:48 Go to next message
Andreas Graf is currently offline Andreas GrafFriend
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 #725617 is a reply to message #725607] Thu, 15 September 2011 11:05 Go to previous messageGo to next message
Jos Warmer is currently offline Jos WarmerFriend
Messages: 114
Registered: October 2010
Senior Member
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 13:40 Go to previous message
Michael Wenz is currently offline Michael WenzFriend
Messages: 1931
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
Previous Topic:Scrolling / zooming programmatically
Next Topic:where to add model listeners to refresh property view
Goto Forum:
  


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

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

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

Back to the top