nick.bollweg at gmail.com
Sat Oct 11 14:23:28 EDT 2014
You can stick the whole thing in an iframe, and it will work pretty much as
it is right now... the crucial bit of magic will be keeping that link
between those two documents. Here is a gist with an untested 20% solution:
Now the widget and the d3 stuff will exist in two separate documents, with
frame with view.frame... the other direction is trickier, and if you end up
needing to do that, just rewrite the whole thing to be outside of a frame :)
- You may want to explore some patterns, like
http://bost.ocks.org/mike/chart/, to encapsulate the relationship
between data/drawing inside the iframe: right now, if a widget were to
- You'll probably want to explore d3.dispatch, so that you can create
custom events (like nodeAdd, nodeRemove, etc) that the widget
can react to.
This may be a cleaner way than trying to "share" data
- be careful of force layout changing your data (nodes, links) in-place,
adding x, y, px, py, etc.
- when a user changes nodes/links form outside the visualization, you'll
probably need to do some things to force... but you'll want to run them at
the same time.
- look at Backbone.Model.changed
<http://backbonejs.org/#Model-changed> and Widget.hold_sync
to make sure that this happens atomically... or get ready for a
lot of svg
All that being said: a well-structured backbone view, which every widget
must be, will be more maintainable in the long run. Just having evented
get/set on the model, and maybe some custom collections, might be worth the
price of admission.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IPython-dev