Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Roassal refactor RubberBand>>onDrop: #872

Closed
seandenigris opened this issue Aug 3, 2015 · 5 comments
Closed

Roassal refactor RubberBand>>onDrop: #872

seandenigris opened this issue Aug 3, 2015 · 5 comments

Comments

@seandenigris
Copy link
Contributor

Originally reported on Google Code with ID 872

ROExample>>rubberBandOn: currently has the line... 
    rawView add: (newEdgeRaw + ROLine).

While this is fine in the ROExample script, in my application rawView was not available
at that point, so instead I needed...
    newEdgeRaw from view add: (newEdgeRaw + ROLine).

For a while I confused myself by trying to use...
    newEdgeRaw view add: (newEdgeRaw + ROLine).

but that was not the same view, since the ROEdge created in the sender had a random
default. 

So I now think it is more clear to not create the ROEdge in the sender, but instead
pass the fromElement and toElement and let the user create the ROEdge themselves. 
I think this is conceptually clearer.

See the two methods in the attached changeset.

Reported by benjamin.t.coman on 2012-11-25 04:55:11


- _Attachment: [RubberBand-20121125.1.cs](https://storage.googleapis.com/google-code-attachments/moose-technology/issue-872/comment-0/RubberBand-20121125.1.cs)_
@seandenigris
Copy link
Contributor Author

Not having the rawView available in your code is probably wrong. You should always pass
the builder through your building code. That is why, for example, all visualizations
in Moose have both a viewXYZ unary method for opening the visualization, and a viewXYZOn:
one for composition purposes.

So, I think this is not a valid concern.

Reported by tudor@tudorgirba.com on 2012-11-25 12:26:33

@seandenigris
Copy link
Contributor Author

It is in Roassal 1.198. This .cs only impact two methods. I would like to see a nice
support of drag and drop in Roassal. This is essential.

Reported by alexandre.bergel on 2012-11-25 14:43:07

  • Status changed: Fixed

@seandenigris
Copy link
Contributor Author

Doru, I'm glad to receive your advice and so I reviewed my code with a critical eye
against all the viewXYZOn: that I could find.  I note that most of the viewXYZOn: seem
to create a whole view having just one or a few different shapes/interactions/layouts
- whereas I am having over 50 shapes with several nestings each with a different layout,
so I have pushed creation of elements out to their matching model classes.  Perhaps
not he best way but it is what I ended up with at the moment and cannot change right
now as I near the finish line of my Masters.  

In any case, even if rawView was available, I think still clearer this way.   It was
only the other way because that is what I came up with myself, and at the time I was
flipping between the two different implementations, and in hindsight this is better.

Reported by benjamin.t.coman on 2012-11-25 15:36:19

@seandenigris
Copy link
Contributor Author

Thanks Alexandre. That works fine.

Reported by benjamin.t.coman on 2012-11-25 15:43:05

@seandenigris
Copy link
Contributor Author

Reported by tudor@tudorgirba.com on 2013-03-03 13:05:26

  • Labels added: Milestone-4.7, Component-Roassal

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant