-
Notifications
You must be signed in to change notification settings - Fork 39
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
Should separate view logic and implementation #11
Comments
What does it mean that we "create a new spring force?" In Classic MW there is the ability to "anchor" atoms to a particular location, which I believe is modeled as a standard "bond/spring" force. There are also external forces that can be applied to objects and these are applied directly as forces in a particular direction. How was the steering force implemented? On Sep 5, 2012, at - September 5 - 11:55 AM, Richard Klancer wrote:
|
@ddamelin , when an atom is dragged, it creates a spring force for the duration of the drag, and removes it when the drag is complete. (@sfentress is the expert here.) This is the implementation of your preferred UI for steering force. (BTW I've started using Github issues to represent code-cleanup tasks that shouldn't clutter up PT or planning meeting discussions.) |
Right. I was just thinking that if we implemented it as a moving anchor (and had a scriptable way to set an anchor), then we get that Classic MW feature, which I use a lot in some of the higher level models like active transport and electron transport chain. -Dan On Sep 5, 2012, at - September 5 - 12:08 PM, Richard Klancer wrote:
|
It is implemented that way. In the model, a spring force is just a force between an atom and an x,y location, and anything could add a spring force (and also update the x,y location of a given force). The view is one instance of something that can add a spring force. Richard is just saying that he wants is such that when the view says, e.g., "can I add a spring-force to this atom?" that it should have to go through an additional view controller, instead of just checking the atom's "draggable" property. This isn't actually about the spring force per se. |
I believe in Classic MW the x,y location and strength of the anchor/spring is an atom property, so that an atom can have only one anchor. In the NextGen steering implementation one needed to click on the draggable atom to initiate the force application, so I'm guessing that it is not stored as an atom property as it is in the mml files generated by Classic MW. An applied force (in both x and y directions) is also an atom property, so we could have used either of these in implementing the steering force. I'm guessing our steering implementation doesn't touch the atom properties. Is that correct? On Sep 5, 2012, at - September 5 - 12:58 PM, Sam Fentress wrote:
|
Let's move any steering-force implementation questions to the lab-models list: https://groups.google.com/forum/?fromgroups=#!topic/lab-models/Z_Mzn__kh94 Let's keep discussion in this issue focused on how, whether, and when to separate molecules view policy from view rendering. |
Code such as the draggable atom view directly creates a new spring force in the associated model. It would be nice for general modularity if the molecule container itself could be slimmed down and just send messages back and forth between itself and a dedicated view controller that implements logic such as deciding when to add a spring force to the model.
In order to make it less painful and error prone do make changes such as adding a view controller, it would also be helpful to first implement a dependency management system such as RequireJS.
The text was updated successfully, but these errors were encountered: