[IPython-dev] Loading nbextension on widget instantiation

Andrew Gibiansky andrew.gibiansky at gmail.com
Tue Jun 17 14:33:14 EDT 2014


When I encountered this, it was particularly surprising, as the behaviour
differed across Chrome and Firefox.

Perhaps it's worthwhile to make this explicit by filtering script tags out
of HTML display_data? That might be way overkill, though.

Anyway, I definitely think it's worth improving this, as I expect it'll
bite more people as more people start developing their own widgets.

-- Andrew


On Tue, Jun 17, 2014 at 10:51 AM, Thomas Kluyver <takowl at gmail.com> wrote:

> On 17 June 2014 06:37, Nicholas Bollweg <nick.bollweg at gmail.com> wrote:
>
>> We have also encountered this issue: we have, for the moment, dealt with
>> it with a mixin for our python-side widget classes that does a require
>> against the _view_name:
>>
>
> Ah, I was trying to load the JS by displaying HTML with a script tag. I
> guess displaying actual javascript directly reduces the async problem. All
> the same, I think a cleaner solution would definitely be good.
>
> I was discussing this with Jon yesterday, and we're thinking of changing
> around the current scheme a bit, so that rather than registering target
> types with the comm manager, and view types with the widget manager,
> widgets are define in modules that can be loaded by require.js. Then a
> widget that currently specifies a view_name will also specify a
> view_module. So in your case, the code would look like this:
>
> class MyWidget(Widget):
>     view_name = 'WidgetView'
>     view_module = '/nbextensions/ipynbdbtk/js'
>     ...
>
> This would result in some incompatibility with existing code, but it
> should be possible to update extensions so that they'll work with IPython 2
> and 3. Given that widgets are new, and the APIs somewhat provisional, I
> think that's acceptable. We intend to update all of our own widgets to use
> this, and get rid of the JS type registries altogether.
>
>
>> Speaking of documentation: a template for building extensions with
>> widgets that that embodied the baseline of knowledge spread all over the
>> community would be great. I have used paste before, which seems kind of
>> heavy these days. Cookiecutter looks good:
>>
>
> I think we're really still working out what best practices are - and
> updating IPython's APIs as we work out things like this. By all means
> create a template, though - it can evolve as our knowledge and APIs improve.
>
> Andrew:
> > I'm not sure, but this *sorta* looks like the same issue I raised in
> the thread titled "Javascript ordering semantics". Here's the solution I
> found then:...
>
> You're quite right, it is exactly the same issue. I wasn't using widgets
> then, so I didn't pay much attention to the thread. I think your solution
> is similar to Nicholas', except with the added publication of an HTML
> element. In my code, the HTML components are created in JS when the widget
> is displayed.
>
> I still think it's worth improving this API in IPython, but I will work in
> this solution to support widgets in IPython 2.
>
> Thanks,
> Thomas
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20140617/987c4492/attachment.html>


More information about the IPython-dev mailing list