[IPython-dev] custom web notebook cells

[Matthias BUSSONNIER]

Le 14 déc. 2012 à 19:32, Brian Granger a écrit :

> Nicholas,
> 
> Hi!
> 
> On Fri, Dec 14, 2012 at 5:13 AM, Nicholas Bollweg
> <nick.bollweg at gmail.com> wrote:
>> 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!
> 
> Can you talk more about the usage cases you have for new cell types?
> Can you give examples?
> 
> The notebook document format is sort of our contract with the
> universe.  We want to be able to have an extremely precise and
> testable definition of what constitutes an IPython notebook, so that
> everyone can open them, share them, convert them, run them etc.  If we
> allow custom cell types, all of that goes out the door, so I don't see
> how we can support custom cell types.  The notebook document format
> would stop being the notebook document format.

I think I have to disagree with you, 
You could make the same remarks with custom joan handler. 
Actually if someone does not have the plugin they might not be able to see 
the json repr. 

And also we have the metadata for people to store almost any information they want.
Also you can imagine people can want custom cell even just to replace our ours for X
reason. 

I don't think they ask us to support those different cell but to allow easier hooks to add them.

But actually think the problem is what you call a **different cell**.
One could have 2 different type of code cell and you can choose which one to get 
with the metadata.

> But, I would like to learn more about your usage cases.  There might
> be other ways of supporting what you want to do:
> 
> * Use an existing cell type with metadata.
> * Provide a custom UI for an existing cell type but don't change the
> notebook format.
> * Actually add a new cell type to the notebook format officially if it
> is something that a majority of our users would use often.

I guess there is a confusion between cell and cell/type.
and looking a blocky it seem the desire cell here is a code-cell, but with 
visual programming where you move block. 


> 
>> 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.
> 
> I am very interested in learning more about this.  Right now my
> jsplugins/handlers branch uses a pretty simple way of installing
> additional Js code = a user just drops it into a special dir in the
> .ipython directory.  It would be nice if these Js plugins were regular
> python modules that could be installed as usual.  But something to
> keep in mind:
> 
> * We have to serve these files on the web.  I don't want to have our
> web server walking all over a users system to pull files as that is a
> huge security risk.  We need to isolate the location of these files.
> * Some plugins don't have any python code so I am not sure it makes
> sense to bundle things into a python package.
> * We need to maintain the ability to install ipython without setuptool.
> 
> Do you have ideas on how we can improve the user experience of
> installing and managing Js plugins?
> 
>> 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.
> 
> That rigidity is merely a reflection of the notebook format.
It is still pretty flexible as long as you respect the structure. 
there are already inconsistencies, 
But if you change code cell `code` field to `source` field then all the cell have almost perfectly the same structure. 
And this structure should be enough for almost any cell type. 

The subtleties going into metadata.
-- 
Matthias