[IPython-dev] custom web notebook cells

Nicholas Bollweg nick.bollweg at gmail.com
Fri Dec 14 08:13:25 EST 2012


hi everybody! longtime user, first time poster.

i've been kicking around a lot of ideas of things to do with ipython
notebook: while the bulk of stuff is clientside, to get there, i think i
need to do custom cells, which is a little more than ellisonbg's
"jsonhandlers" branch does. further, as the specific capabilities exposed
will require some pretty big depndencies (pdf generation, numpy, etc.) I am
thinking about doing everything as python modules that are installed into
the environment, rather than as purely drop-in javascript assets.

i've started the work on github here:
https://github.com/bollwyvl/ipython/tree/custom_cells

and a strawman cell provider here (does not contain working code, though it
does load!):
https://github.com/bollwyvl/ipython/tree/blockly

any insight is welcome!

to get my stuff in, i have used the setuptools iter_entry_points method I
am familiar with... and defined a new entry_point, ipnotebook. plugins
provide their list of assets and where one might find their static paths.
can anyone comment on how this is (potentially) different from The IPython
Way? The extensions stuff in the doc didn't look like they would be useful,
so i gave up on trying to use that.

the structure of working with cells in master is pretty rigid right now,
with the enumerated list of cells type in the code explicitly in the front
end in several places, js and html. my initial work (in a addition to
inadvertently recreating some of ellisonbg's work on the tornado app) has
been to refactor all of those cases of adding buttons or whatever into
something that looks at a window.IPython-scope plugin registry.... this is
defined in cell.js right now, but maybe should be someplace else.

after i did discover ellisonbg's stuff, i saw the most recent work was on
dependencies... during my stuff, i will look into frontend and backend
asset managers: require.js and webassets come to mind. this would have the
pleasant benefit of clearing up some of the mathjax complications, and
would make plugin development a lot more robust, if not simpler... also, if
a user installed the kitchen sink of plugins, which started adding a lot of
javascript assets, ideally a user should not see significant notebook
slowdown until they were actually using new features.

looking forward to working on this over the holidays, and would love to
have some fun things to show come 2013!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20121214/3f683198/attachment.html>


More information about the IPython-dev mailing list