<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">When we load the index.html from the javascript file we use:<div><span class="Apple-tab-span" style="white-space:pre">    </span>this.$frame = $("<iframe/>", {<div>      <span class="Apple-tab-span" style="white-space:pre">              </span>src: "index.html"</div><div>        <span class="Apple-tab-span" style="white-space:pre">      </span>})</div><div>Is that mean the index has to be in the same directory as the opened notebook ? because the user can open a notebook from anywhere he want, so in the case it’s not working. </div><div><br></div><div><div>Le 11 oct. 2014 à 20:23, Nicholas Bollweg <<a href="mailto:nick.bollweg@gmail.com">nick.bollweg@gmail.com</a>> a écrit :</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div>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:<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><a href="https://gist.github.com/bollwyvl/f0ba3e16a5a824d53dc8">https://gist.github.com/bollwyvl/f0ba3e16a5a824d53dc8</a><br></blockquote></div><div><br>Now the widget and the d3 stuff will exist in two separate documents, with two different javascript contexts, but from the view you can touch the 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 :)<br></div><div><ul><li>You may want to explore some patterns, like <a href="http://bost.ocks.org/mike/chart/">http://bost.ocks.org/mike/chart/</a>, to encapsulate the relationship between data/drawing inside the iframe: right now, if a widget were to update</li><ul><li>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</li></ul><li>be careful of force layout changing your data (nodes, links) in-place, adding x, y, px, py, etc.</li><li>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.</li><ul><li>look at  <a href="http://backbonejs.org/#Model-changed">Backbone.Model.changed</a> and <a href="http://ipython.org/ipython-doc/dev/api/generated/IPython.html.widgets.widget.html#IPython.html.widgets.widget.Widget.hold_sync">Widget.hold_sync</a> to make sure that this happens atomically... or get ready for a lot of svg errors.</li></ul></ul><p>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. </p><p>Good luck!<br></p></div></div>
_______________________________________________<br>IPython-dev mailing list<br><a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>http://mail.scipy.org/mailman/listinfo/ipython-dev<br></blockquote></div><br></div></body></html>