Bumping this one up again (after 2 years of silence), as its still not possible to efficiently integrate plotly for multiple paragraphs in zeppelin.
WDYT about my suggestion. I can prepare a PR for that... > Therefore I'm again suggesting a new configuration property to allow zeppelin > administrators to include any kind of special JS code (most likely referenced > via an URL) to the html->head section. I'm not sure yet, if thats possible at > all, because configuration is some information from the server, that needs to > be loaded very early. Best Regards Andreas On 2018/08/15 06:26:48, andreas.we...@gmail.com <andreas.we...@gmail.com> wrote: > > > Thanks for your answers, but as long as custom JS code resides in html->body > (which is the case for any code loaded through notebooks) there is no > guarenteed loading sequence when using the default HTML outputs of libs like > plotly, which assume that all of the library code is already loaded. Of > course you can add more custom complex JS code (promise etc.) to sort these > issues per notebook, but that is not very enduser friendly. > > bokeh loads all of its JS resources in the html->head, which is why things > work there. And this is different to zeppelin, where everything is loaded in > the body. > https://github.com/bokeh/bokeh/blob/master/bokeh/core/_templates/file.html > > The point here is, that in zeppelin there is currently no feasible way to add > this kind of central customization to the html->head section, neither for > loading Libs from CDN nor loading JS code asynchronously (like bokeh). > (without rebuilding zeppelin-web.war) > > Therefore I'm again suggesting a new configuration property to allow zeppelin > administrators to include any kind of special JS code (most likely referenced > via an URL) to the html->head section. I'm not sure yet, if thats possible at > all, because configuration is some information from the server, that needs to > be loaded very early. > > Or can this be achieved via helium (or an extension to helium). > > Or any other idea how to solve this centrally and not on a per notebook base? > > Regards > Andreas > > On 2018/08/14 08:27:16, Jeff Zhang <zjf...@gmail.com> wrote: > > Here's the code of how bokeh loading js asynchronously, hope it is useful > > for you. > > > > https://github.com/bokeh/bokeh/blob/master/bokeh/core/_templates/autoload_js.js > > > > > > Partridge, Lucas (GE Aviation) <lucas.partri...@ge.com>于2018年8月14日周二 > > 下午4:21写道： > > > > > I’m pretty rusty on this as it’s several years since I tried it but I > > > remember having a similar problem when trying to use Google Maps inside > > > Zeppelin. Unfortunately I can’t find the code I used but from memory, my > > > solution was to try invoking the library, and if, the library object > > > didn’t > > > exist, load it. In the onload() callback (not sure I’ve remembered the > > > method’s name right) I would then draw my map. I certainly didn’t embed > > > the > > > library in the notebook itself. > > > > > > > > > > > > *From:* Jeff Zhang <zjf...@gmail.com> > > > *Sent:* 14 August 2018 08:11 > > > *To:* users@zeppelin.apache.org > > > *Subject:* EXT: Re: Inefficient third party JS library integration, e.g. > > > plotly > > > > > > > > > > > > > > > > > > Do you know how jupyter handle that ? And bokeh would load js from CDN so > > > it doesn't have the issue you mentioned, maybe plotly could use similar > > > approach. > > > > > > > > > > > > https://bokeh.pydata.org/en/latest/ > > > > > > > > > > > > > > > > > > > > > > > > andreas.we...@gmail.com <andreas.we...@gmail.com>于2018年8月14日周二 下午2:34写道： > > > > > > We are using plotly for charts quite often (plotly python in conjunction > > > with pyspark) and it reavels a weakness regarding to third party JS > > > library > > > integration. > > > > > > Unfortunately current plotly integration is not very efficient in terms of > > > library integration, which leads to huge notebooks. This is because > > > notebooks that contain plotly will have to output the full js code of > > > plotly. (~3MB). When a Notebook contains several of that integration, the > > > notebook becomes very slow. I think this also applies to other js > > > libraries. > > > > > > E.g. for plotly you can render charts in zeppelin the following way with > > > pyspark (the first print is only for demoing the actual html output in > > > cleartext): > > > --------------------------------------------- > > > %pyspark > > > from plotly import graph_objs as go > > > from plotly.offline import plot > > > > > > out = plot([go.Scatter(x=[1, 2, 3], y=[3, 1, 6])],include_plotlyjs=True, > > > output_type='div') > > > > > > print(out) > > > print('%html', out) > > > --------------------------------------------- > > > > > > An alternative would be, to load plotly.js (or any other third party > > > library) from a CDN, e.g. > > > <script src="https://cdn.plot.ly/plotly-latest.min.js";></script> (and > > > settings include_plotlyjs in the example above to false, which would lead > > > to the bare minimum of code for that specific chart). > > > But this needs to be added to the html->head, otherwise any dependent code > > > using that library might run into 'Uncaught ReferenceError: ... is not > > > defined' issues, due to timing. > > > > > > I found that setup guide for repacking the zeppelin-web archive, to > > > include a custom library in the index.html, but IMHO that seems to be a > > > workaround: > > > https://github.com/beljun/zeppelin-plotly > > > > > > Therefore I would suggest to add some zeppelin server wide configuration > > > to allow zeppelin administrators to include additional <script> directives > > > in the head section. > > > > > > Any other recommendation / ideas to solve the timing issue? > > > > > > > > >
