Please, review this: @Tyagov, @kirr and @tatuya.

Kernel improvements:

• Automatically render last-returning objects as HTML through "processors"
  • These so called "processors" are classes responsible for rendering certain objects as HTML depending on their type
  • The user can add his own customized processors, either by editing the JupyterCompile extension itself or using the variable _processor_list in the code cells

ERP5 Jupyter kernel integration with PivotTableJs

• Implemented as an external method that receives a Pandas.DataFrame as parameter, along with the url of the ERP5 instance (is there a way to detect this instead of hardcoding all the time?)
• Works through an IPython.lib.display.IFrame object, that is added to the result of the code cell. Inside this IFrame the pivot table will be rendered with data from the DataFrame
• The IFrame is stored/hosted in the (volatile, for now) memcached sever of the instance, using his own HTML representation as key and accessed through a Script (Python) object

Notes

There's more detailed information about the implementation in the commit messages and a little bit more in comments inside the JupyterCompile extension, where the kernel lives.

The demo web page included in the bt5 will only work if the Wendelin software release is installed, as it depends partially on things from the ERP5 repository and part from things on the following merge request to Wendelin: wendelin!10 (merged) . Should I move it there or keep it here?

I'm still refactoring to completely remove those global variables from the code. Will add the commit here ASAP.

Global variables completely removed!