[IPython-dev] [sympy] Re: using reST for representing the notebook cells+text

[Ondrej Certik]

On Wed, Feb 24, 2010 at 11:15 AM, Brian Granger <ellisonbg at gmail.com> wrote:
>> I will do reST import/export, but having it the default format, that I
>> think sucks. With xml, anyone can easily write a parsers for it in any
>> language.
>>
>> Besides, I need to push the worksheet to the browser. In my case, I
>> use pyjamas, so it's pure Python, however, exec/eval are not evailable
>> there (as far as I know), but I am sure xml would work, here is some
>> code to handle xml in pyjamas:
>
> A point of clarification.  The Notebook and Cell objects would not be
> responsible
> for the execution of python code.  The execution logic would simply
> pull InputCells
> out of the Notebook, extract the python code (as a str) and return the
> OutputCell.
>
> [Thinking out loud about what this might look like in a web
> browser....more thought needed]
>
> The Python Notebook and Cell objects would not be pyjamas entities - that
> part of the python code would not be compiled to Javascript.  The
> Notebook and Cell
> objects would live in the web server and be capable of rendering
> themselves as json
> or html.
>
> The pyjamas classes would contain the logic for the user interface,
> and calling out to the
> Notebook/Cell web service and pass XML/json back and forth....

That's right. I just did more studying of this and I don't want to
parse xml by hand in javascript/pyjamas. I would like to use the
builtin functionality
 for RPC, essentially, you just call python methods on both sides and
things get automatically transfered (using json/xml RPC) behind the
scene, it's very convenient.

>
>> I think, that it might work to push the whole Python objects somehow
>> (that's the nice thing about pyjamas, that since you have python on
>> both sides, you can do lots of cool stuff), but maybe not.
>
> Yes, that might work.  I have been thinking about the Cell objects as having
> all the logic needed to render itself in various formats.  But maybe a
> Cell object
> itself could be lighter weight - the rendering logic could be a separate class.
> Then the Cell objects could be compiled to JS using pyjamas.  But I am
> not familiar
> with how pyjamas works enough to see if this would work.
>
>> I like Brian's idea to be able to just import it in Python. But I
>> think I'll just stick to xml for the first iteration of my notebook,
>> to get the job done.
>
> Definitely don't wait for me to implement my idea...I do agree with
> your statement about
> the ease of parsing XML though.

Here is my current code, that runs in the browser:

http://github.com/certik/sympy_gamma/blob/login/templates/nb.py

and here is the code, that runs on the server, listens at some url
(/eval_cell/...) and evaluates the cell:

http://github.com/certik/sympy_gamma/blob/login/app/views.py#L126

it's just 15 lines, 7 of those are debug prints.


So there is no way to remember sessions, worksheets anything yet. So I
will have Notebook/Cells on the server, the eval_cell() method will
(besides the actual evaluation) keep the tree structure of
Notebook/Cells updated. This structure will know how to export/import
to/from many formats (reST, xml, ...), that part is clear.

The rendering itself is done using pyjamas, so the Notebook/Cells
classes don't need to know anything about it, they just contain the
logic.

On the browser part, I will also need some
Notebook_pyjamas/Cell_pyjamas classes, that are purely responsible for
rendering and I need somehow to initialize them from the server. I
think I will do that by implementing Notebook_pyjamas.add_cell()
method, that will be exported using RPC to the server, so the server
will call this method as many times as needed, and add there
parameters (input_text, output_text, type_of_the_cell="text"/"eval").

This would also solve my problem with passing data to the pyjamas app.
So far I passed it by saving it to the "meta" tags in the header of
the html page, and then getting it from inside pyjamas. But it sucks,
it's not very versatile. See e.g. here the code to read it:

http://github.com/certik/sympy_gamma/blob/login/templates/nb.py#L453

it reads the html elements and returns a Python dict with the options.
It's very fragile.


So this pyjamas development is a bit different to what one was used to
before (e.g. generating the html on the server), essentially the
philosophy is to initialize "Python" in the browser as soon as
possible and then do everything on the Python level. And generate all
html in the browser itself, from Python by constructing appropriate
pyjamas GUI widgets (e.g. I subclassed the TextArea widget that
implements the html textarea, with backspace/tab, shift+enter,
correctly resizing it, calculating (x, y) coordinates of the cursor
/nontrivial.../, etc, etc). It's kind of a fake, since there is no
Python in the browser, just javascript, so it took my a while to
realize that I can think of this really as having a Python interpreter
in the browser (resp. a static subset of Python).

Ondrej