Formalize the communication protocol (no more eval) about flexx HOT 7 CLOSED

(this might be a possible approach for Bokeh to do its widgets)

from flexx.

There has been an occurance where Chrome would block JS in a flexx app, probably because of the eval that we use. Using a formalized protocol should get rid of that.

from flexx.

mmm... now that I think of it, that's not entirely true. Model classes that are defined after the page has been served will be dynamically defined, using eval. Well, at least eval would be used way less.

from flexx.

Related to #143

from flexx.

Mmm, it seems that eval() would be a good way to load modules dynamically, and still have them show up as "files" in the debugger, using //# sourceURL=hello.js.

Eval is not necesarily evil, as long as you do it in a way that does not allow misuse. Since the server sends the source over a websocket, I don't think this is a problem. Arguments about performance don't matter these days.

We might want to look at https://developer.chrome.com/extensions/contentSecurityPolicy to prevent the Chrome browser from blocking eval, though.

from flexx.

Did you also see this variant on the same scheme? Serving a JS file that has //@ sourceURL=foo.js at the beginning will also show it in the devtools.

http://stackoverflow.com/a/18007439/552379

from flexx.

Had a look at the protocol during some of the late app refactoring. Most commands consist of a command and then a string. There are a few exceptions of commands that have more "arguments", but they can safely be space-splitted. Commands that are just strings also have advantages, e.g. in exported notebooks. Therefore, I chose to leave it as is. The commands can still be formalized, though I don't think there is much need while its only our Py and our JS talking to eachother.

from flexx.