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

Should separate view logic and implementation #11

Open
rklancer opened this issue Sep 5, 2012 · 6 comments
Open

Should separate view logic and implementation #11

rklancer opened this issue Sep 5, 2012 · 6 comments

Comments

@rklancer
Copy link
Contributor

rklancer commented Sep 5, 2012

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.

@ddamelin
Copy link
Contributor

ddamelin commented Sep 5, 2012

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:

Code such as the draggable atom view directly creates a new spring force

@rklancer
Copy link
Contributor Author

rklancer commented Sep 5, 2012

@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.)

@ddamelin
Copy link
Contributor

ddamelin commented Sep 5, 2012

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:

@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.)


Reply to this email directly or view it on GitHub.

@sfentress
Copy link
Collaborator

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.

@ddamelin
Copy link
Contributor

ddamelin commented Sep 5, 2012

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:

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, e.g., the view says "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.


Reply to this email directly or view it on GitHub.

@rklancer
Copy link
Contributor Author

rklancer commented Sep 5, 2012

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.

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

3 participants