andrew.gibiansky at gmail.com
Sat May 17 02:37:32 EDT 2014
unsure whether I am doing something wrong in my architecture, or if perhaps
IPython should somehow mitigate the bugs I'm getting.
Basically, here's the setup: for IHaskell, extension authors who want to be
able to display their data as widgets must create a way to register those
widgets. The first time those widgets are created, they must also be
registered in the JS on the notebook frontend. However, this is done in the
same series of messages as the comm_open. So here's the crux:
The way that the widgets are registered is by adding a <script> tag to the
DOM. However, though the DOM is added, I *think* the comm_open message is
parsed *before* the <script> in the DOM is executed. Note that this
in firefox. In Chrome, the <script> tag is added, the DOM is executed, and
*then* the comm_open is processed. By the time comm_open is processed in
Chrome (not in firefox), the <script> has been run so the widget is
registered. In firefox, the comm_open is processed before the script tag
was run, so the widget is unregistered.
So here's my question:
Would it be possible to *force* all DOM added as a result of message
handling to be parsed and script tags in it to be executed before the next
message is handled? Perhaps this could be done by using $(blah).load(...)
on everything that is added to an output area? Or something?
Anyway, I am confused, and not sure how to fix this, and whether or not
it's an issue with my code. The one requirement is that when the widget
object is evaluated is the first time that the relevant widget is
registered (if it is necessary); that is, that when the kernel sees the
widget, it first sends a display_data to which has some scripts to register
the widget, and then opens the comm via comm_open.
-- Andrew Gibiansky
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IPython-dev