<br><br><div class="gmail_quote">On Tue, Jan 8, 2013 at 4:18 PM, Brian Granger <span dir="ltr"><<a href="mailto:ellisonbg@gmail.com" target="_blank">ellisonbg@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">On Tue, Jan 8, 2013 at 2:09 PM, MinRK <<a href="mailto:benjaminrk@gmail.com">benjaminrk@gmail.com</a>> wrote:<br>
><br>
><br>
> On Tue, Jan 8, 2013 at 2:04 PM, Brian Granger <<a href="mailto:ellisonbg@gmail.com">ellisonbg@gmail.com</a>> wrote:<br>
>><br>
>> Using the JS Plugins branch, you can use the following model:<br>
>><br>
>> * Write a JS plugin that has all of the javascript code you need - you<br>
>> can do whatever you want.<br>
>> * That Js plugin will declare a handler for a particular type of data.<br>
>> * You can then publish JSON data to that handler using appropriate Python<br>
>> calls.<br>
>><br>
>> You shouldn't ever need to use the existing Javascript object to write<br>
>> your JS code.<br>
><br>
><br>
> I don't think doing away with inline js is remotely feasible.<br>
> For security reasons, we have to make decisions like:<br>
><br>
> on load, do not run raw js, because it could do terrible things without the<br>
> user being aware.<br>
><br>
> But removing the general ability to run js without installing new files on<br>
> the nb *server* cannot possibly be the long-term solution.<br>
<br>
</div>Originally, I (obviously) thought this way.  But, as I have learned<br>
more about the security vulnerabilities, I have become convinced that<br>
this is the long term solution.  However, I am open to other solutions<br>
that 1) completely remove the security risks and 2) don't involve<br>
significant new complexities, such as requiring multiple domains and<br>
iframes.  I should also note that I am open to the single user<br>
notebook preserving this capability - but I am a little hesitant to<br>
leave it enabled as it will encourage people to write Javascript code<br>
in this way.<br></blockquote><div><br></div><div>I do appreciate the concern, and we need a solution to the issue.</div><div>I just don't think we have a complete one yet.</div><div>Right now, we have a supremely flexible (and thus insecure) situation,</div>

<div>whereas jsplugins-only is secure, but not remotely flexible from a user's perspective.</div><div><br></div><div>This is an extremely serious incapacitation of the notebook.</div><div>The trouble is that jsplugins is a relatively tolerable substitue</div>

<div>for the single-user notebook, but where the problem is worst</div><div>is when users don't actually have access to the server</div><div>to install jsplugins.  So it's precisely the case where we</div><div>would not allow custom js that jsplugins fail most dramatically</div>

<div>as a substitute.</div><div><br></div><div>Is it really our intention to require *server* installation of a plugin</div><div>for a user to gain access to a new widget? That seems to eliminate a *huge* portion of exactly what makes the notebook interesting.</div>

<div><br></div><div>If we have a way that js plugins can be loaded at runtime by the user without access to the server (presumably with a 'do you trust this guy?' confirmation),</div><div>then that would go a long way toward preventing the total castration of the notebook.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
A separate issue is that actually writing Javascript code using the<br>
old Javascript object is horrifically painful.  Errors get completely<br>
swallowed and it is nearly impossible to figure out what is going on.<br>
I think this is why very few people have actually done anything<br>
significant with the Javascript object we currently have - it just<br>
doesn't work very well.  On the other hand, developing the JS plugins,<br>
gives the usual mostly pleasant development experience.<br></blockquote><div><br></div><div>This isn't entirely accurate, as errors in js do show up in the notebook. Just try</div><div><br></div><div>%%javascript</div>

<div>a = doesnt_exist</div><div><br></div><div>But I do appreciate the pain - I've taken to writing new inline js code in .js files locally,</div><div>just so my editor can help me out, which is similar in practice to jsplugins and definitely an improvement over typing js in Python strings.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
<br>
Brian<br>
<div class="HOEnZb"><div class="h5"><br>
>><br>
>><br>
>> Cheers,<br>
>><br>
>> Brian<br>
>><br>
>><br>
>> On Tue, Jan 8, 2013 at 1:11 PM, lecast <<a href="mailto:martin.zmk@gmail.com">martin.zmk@gmail.com</a>> wrote:<br>
>> > Thx. I will have a look at both the repository and the pull.<br>
>> ><br>
>> > Returning Javascript() or HTML() is not exactly what I need. In general<br>
>> > I<br>
>> > always need  to publish both html and javascript within a function so<br>
>> > that<br>
>> > function that would correspond to make_table() from ipy_table creates<br>
>> > both<br>
>> > the element and the script that populates that element. But this is mute<br>
>> > here, since I couldn't find a way to copy final elements from the window<br>
>> > and<br>
>> > saving them in the notebook for good, the only thing that actually is<br>
>> > saved<br>
>> > is the final html object.<br>
>> ><br>
>> > I don't use inline JS anywhere there. But, if you prevent inline JS in<br>
>> > output then you will also prevent a lot of interactivity on final output<br>
>> > that e.g. d3 generates. I mean you need to be able to have things like<br>
>> > onClick etc. But if you mean that you will prohibit me from saving<br>
>> > javascript in any form in the notebook, then I will probably have to<br>
>> > stop<br>
>> > pulling the new versions... Right now I spend all my time in Notebook,<br>
>> > i.e.<br>
>> > I wrote a script that converts notebooks to latex and I just write my<br>
>> > papers<br>
>> > in Notebook. It is nice since I see my math instantly, but I need to be<br>
>> > able<br>
>> > to embed some javascript that appears only in those notebooks that are<br>
>> > really papers, e.g. to replace references or make highlights (<br>
>> > <a href="http://i46.tinypic.com/163qyg.png" target="_blank">http://i46.tinypic.com/163qyg.png</a> ).<br>
>> ><br>
>> > Customjs is ok unless you send the notebook to someone and don't tell<br>
>> > them<br>
>> > they need to have it as well. I wanted something that produces output<br>
>> > that<br>
>> > is easily replicable.<br>
>> ><br>
>> ><br>
>> ><br>
>> > Z wyrazami szacunku,<br>
>> > Marcin Zamojski<br>
>> ><br>
>> ><br>
>> > On Tue, Jan 8, 2013 at 8:56 PM, Matthias Bussonnier [via Python]<br>
>> > <[hidden<br>
>> > email]> wrote:<br>
>> >><br>
>> >> Hi !<br>
>> >><br>
>> >> It look really great :<br>
>> >><br>
>> >> A few comment :<br>
>> >><br>
>> >> Obstacle 1<br>
>> >> def x():<br>
>> >>         from IPython.core.display import Javascript<br>
>> >>         Javascript('alert("a")')<br>
>> >> x()<br>
>> >><br>
>> >> you probably want to `return Javascript('alert("a")')`<br>
>> >> Am I wrong ?<br>
>> >><br>
>> >><br>
>> >> Obstacle 2:<br>
>> >>  same : `return HTML()` I guess...<br>
>> >><br>
>> >> Please, please, please don't inline script.<br>
>> >> We will in anyway prevent script in output so this will become useless<br>
>> >> anyway.<br>
>> >> Which will deprecate _js_repr_ (at least make it useless) but Brian<br>
>> >> Json-handler branch<br>
>> >> ill work much better to do what you want.<br>
>> >><br>
>> >> Obstacle 3/Obstacle 4<br>
>> >> Will be solve with brian Json Handler branch.<br>
>> >><br>
>> >> You probably want to inject your own library in the notebook,<br>
>> >> which can be done via custom.js<br>
>> >><br>
>> >> draft doc :<br>
>> >> <a href="http://elacave.lmdb.eu/~carreau/yui/classes/IPython.customjs.html" target="_blank">http://elacave.lmdb.eu/~carreau/yui/classes/IPython.customjs.html</a><br>
>> >> use $.getScript(url)<br>
>> >> for example :<br>
>> >> $.getScript('d3.min.js') in you have d3.min.js in<br>
>> >> .ipython/profile_xxx/static/js/d3.min.js<br>
>> >><br>
>> >> You might be interesting in<br>
>> >> <a href="http://epmoyer.github.com/ipy_table/" target="_blank">http://epmoyer.github.com/ipy_table/</a><br>
>> >><br>
>> >> To join effort.<br>
>> >><br>
>> >> Thanks.<br>
>> >> --<br>
>> >> Matthias<br>
>> >><br>
>> >><br>
>> >><br>
>> >><br>
>> >> Le 8 janv. 2013 à 17:26, lecast a écrit :<br>
>> >><br>
>> >> > This is a new thread but it is born out and related to a  previous<br>
>> >> > discussion<br>
>> >> ><br>
>> >> ><br>
>> >> > <<a href="http://python.6.n6.nabble.com/experiment-remote-execution-of-jquery-and-d3-code-into-the-browser-via-ipython-td4633053.html#a4955237" target="_blank">http://python.6.n6.nabble.com/experiment-remote-execution-of-jquery-and-d3-code-into-the-browser-via-ipython-td4633053.html#a4955237</a>><br>


>> >> > . The goal there was to live update figures created with d3js in<br>
>> >> > IPython<br>
>> >> > Notebook. It was suggested that a solution would be to use widgets,<br>
>> >> > which I<br>
>> >> > have to admit I did not have time to understand so instead I decided<br>
>> >> > to<br>
>> >> > create something that produces the end product I was aiming at, i.e.<br>
>> >> > take<br>
>> >> > output from Python, use d3js to create a table/figure, use some<br>
>> >> > blackbox,<br>
>> >> > have the output visible in the notebook (or be able to save it<br>
>> >> > elsewhere<br>
>> >> > as<br>
>> >> > svg/html/png/etc).<br>
>> >> ><br>
>> >> > You can find an example notebook with a lot of custom tables and some<br>
>> >> > figures  here <<a href="http://nbviewer.ipython.org/4484816/ipyD3sample.ipynb" target="_blank">http://nbviewer.ipython.org/4484816/ipyD3sample.ipynb</a>><br>
>> >> > .<br>
>> >> > They are all created based on data from Python, rendered in PhantomJs<br>
>> >> > (in<br>
>> >> > that case I just copy the html, but PhantomJs allows for conversion<br>
>> >> > to<br>
>> >> > other<br>
>> >> > formats), and then published in the notebook.<br>
>> >> ><br>
>> >> > I created it for myself, so there is hardly any commenting in the<br>
>> >> > file<br>
>> >> > (I<br>
>> >> > know, bad), but I have been using it for a few months now and it<br>
>> >> > works<br>
>> >> > really well. D3js has some great modern visualizations coded in and<br>
>> >> > it<br>
>> >> > takes<br>
>> >> > only a few days to learn the syntax by doing.<br>
>> >> ><br>
>> >> > Personally I think it would be really nice to make it into an<br>
>> >> > extension/package, but I lack experience/time to do that.<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > --<br>
>> >> > View this message in context:<br>
>> >> > <a href="http://python.6.n6.nabble.com/D3js-and-IPython-tp5001661.html" target="_blank">http://python.6.n6.nabble.com/D3js-and-IPython-tp5001661.html</a><br>
>> >> > Sent from the IPython - Development mailing list archive at<br>
>> >> > Nabble.com.<br>
>> >> > _______________________________________________<br>
>> >> > IPython-dev mailing list<br>
>> >> > [hidden email]<br>
>> >> > <a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
>> >><br>
>> >> _______________________________________________<br>
>> >> IPython-dev mailing list<br>
>> >> [hidden email]<br>
>> >> <a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
>> >><br>
>> >><br>
>> >> ________________________________<br>
>> >> If you reply to this email, your message will be added to the<br>
>> >> discussion<br>
>> >> below:<br>
>> >> <a href="http://python.6.n6.nabble.com/D3js-and-IPython-tp5001661p5001692.html" target="_blank">http://python.6.n6.nabble.com/D3js-and-IPython-tp5001661p5001692.html</a><br>
>> >> To unsubscribe from D3js and IPython, click here.<br>
>> >> NAML<br>
>> ><br>
>> ><br>
>> ><br>
>> > ________________________________<br>
>> > View this message in context: Re: D3js and IPython<br>
>> ><br>
>> > Sent from the IPython - Development mailing list archive at Nabble.com.<br>
>> ><br>
>> > _______________________________________________<br>
>> > IPython-dev mailing list<br>
>> > <a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
>> > <a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
>> ><br>
>><br>
>><br>
>><br>
>> --<br>
>> Brian E. Granger<br>
>> Cal Poly State University, San Luis Obispo<br>
>> <a href="mailto:bgranger@calpoly.edu">bgranger@calpoly.edu</a> and <a href="mailto:ellisonbg@gmail.com">ellisonbg@gmail.com</a><br>
>> _______________________________________________<br>
>> IPython-dev mailing list<br>
>> <a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
>> <a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> IPython-dev mailing list<br>
> <a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
> <a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
><br>
<br>
<br>
<br>
--<br>
Brian E. Granger<br>
Cal Poly State University, San Luis Obispo<br>
<a href="mailto:bgranger@calpoly.edu">bgranger@calpoly.edu</a> and <a href="mailto:ellisonbg@gmail.com">ellisonbg@gmail.com</a><br>
_______________________________________________<br>
IPython-dev mailing list<br>
<a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
</div></div></blockquote></div><br>