We use a lot of HTML canvas widgets and developing them within the Ubidots webapp is difficult, and trying to copy them to different dashboards is also difficult - copy the JS libs one by one, copy the HTML/CSS/Javascript tab contents…
It would be great to have an export & import function that took a single HTML file that used comments to delimit each section or js lib. This HTML file could be used to develop the widget standalone, and then have an option in either the dasbhoard add widget function, or in the HTML canvas menu to import and parse this HTML file into the properties & fields of the widget.
We have a single file HTML template we use for development, but we still have to copy/paste bits of it all over the place in the widget properties.
There are still some tricks to it, such as getting the right device ids into it, but being able to do most of the work with a single import operation would be great.
I see the dashboard JSON object has a widgets URL in it, so called that, and that gave a seemingly complete description of the widgets on the dashboard, including the html, css, javascript, and libs of the canvas widgets.
So that’s promising!
The API documentation does not give any description of the widget object or any CRUD REST calls related to them, nor a way to get a specific widget from a dashboard.
Hello @david.a.taylor ,
Thank you for reaching out to our Community Forum.
We understand your need for being able to quickly and easily reproduce and distribute your created HTML Canvas widgets to other Dashboards. At the moment we are working on a Development in order to solve this inconvenient. I don’t know an ETA or the exact details of how the solution would look like, but I do know that there is some work on that at the moment.
In the meantime, I’d like to clarify that although the Widget CRUD Requests that you made worked (and I’m glad that they did, great job BTW), they aren’t present in our API Docs because they aren’t made yet for a stable documentation. That is, all of the Widget/Dashboard CRUD endpoints, query params, properties and so forth may change without any notice as we make changes/fixes, which is why we don’t publish them as available endpoints in our API.
I have worked around this constraint by bundling my HTML, CSS, and JS with Webpack and then hosting the resulting script on static web hosting and adding a single <script src="{url_to_bundle}">. HTML is loaded with a Webpack plugin and then loaded using document.body.insertAdjacentHtml. CSS is also loaded with a Webpack plugin. If any configuration need be applied to the script, a script tag is added before the bundle script with a window-level configuration object. Creating a canvas widget is much less tedious this way, because only a single script import and configuration is required.
Thanks Sebastian. I look forward to being able to work with widgets via REST.
Dan, thanks for the idea. I was trying to paste the content of the single HTML file we develop with into the widget but that resulted in invalid HTML when sent to the browser.
I’ve revisited this after having to update the same custom widget on two different dashboards.
What I have made work so far is:
A single div in the HTML tab: <div id="xyz"/>.
Include my CSS in the CSS tab: @include url("https://...");
Include my JS as a 3rd party library.
The JS has the HTML in it as a template literal so it can be multiline etc.
The JS tab of the widget only has enough code to customise the instance of the widget and then calls the widget_main(…) function of the script loaded as a library.
First thing the script does is replace the outerHTML of #xyz with the HTML from the script, then it goes on to do API calls etc.
BTW, I was really pleased to see all the example code in the HTML canvas widget when I created a new one. That was new.