Here are my suggestions regarding the Generic JavaScript View node:
- in the first tab (JavaScript View), one has to create oneself the DOM through JS (i.e. including the typical declarations such as HEAD, BODY, etc.) while pure HTML tags are not accepted, why not ? This may be excellent for coders who feel very comfortable with JS but constitutes a hurdle for JS beginners. Why not allow this window to interpret HTML tags with scripts embedded in a <script> tag ?
- the second tab (image generation) is quite complicated in use absent the appropriate knowledge of JS. My guess is that this tab should really be a separate node à la "JS View to Image".
thank you for your feedback on the node. We really appreciate your input!
The idea of having an input field for static structural HTML elements is definitely worth considering as this does provide a little bit of an overhead in the JavaScript.
A few remarks on the comments:
You don't need to define head or body tags, this is all present in the DOM already, when your script runs. It is also important to know that defined dependencies (like D3 and jQuery) will also be already loaded and available for use during the time your script runs.
If you simply want to define a static HTML output, maybe the TextOutput Quickform node is more suited for that. Here you can choose the HTML mode, type in your HTML structure and also use flow variables. However you have no (or very limited) JavaScript possibilities when using that node.
To use the second tab (image generation) you have to have a return statement, which returns an SVG structure as a string. There is an example in the node description that should explain this quite well. A seperate node to fetch an image is not possible, since the view is only present in the context of one node.
In general the Generic JavaScript view node is still work in progress and will have additional features and possible better handling with every upcoming release.
I'm a bit surprised that the Generic JS view node does not simply consist of a single code window (à la R node) with a few code templates or examples (which could include JS code wrapped in a HTML markup) to know what the KNIME node expects.
My observation so far is that most D3 code examples (in books or the web) are wrapped into HTML, with the usual script references or JS code as well as style elements. Now I understand it that the styling tab as well as the D3 dependencies get automatically included in the Node and so the need for a proper HTML skeleton is probably drastically reduced.
However, also take into consideration the following use cases:
you want to copy & paste the example code to start from the web and adapt it for your purposes. How to adapt the code to make it work in the KNIME node ?
you want to include another version of the D3 library or even other JS libraries or functions. Isn't the node called Generic ? ;-)
Finally, based on what does this KNIME view render the code ? Does it produce intermediary markup code first which would get then fed to a browser component ? If the latter were the case, it would be a nice feature to be able to access the said code after execution (for debugging and export purposes).
An HTML input component is definitely worth considering, we could even include the (already present) HTML skeleton as an uneditable wrapper around it, as to get a sense of the context.
If you want to include another JS library you can use requireJS to do so. As a starting point take a look at this comment. We are also thinking about making this easier in the future and include a customizable list of external libraries to the node dialog. This will work for most libraries, but some cases where plugins depend on other plugins to be loaded will be a little harder to model.
The view is generated depending on the context in which it runs. If you open the view on your local machine an HTML skeleton page is generated and settings, data and code are injected as needed. All JavaScript enabled views will also be able to run in the KNIME WebPortal. Here it is a little bit different, since many views might appear on one page and a layout for those views might be present. We have another JavaScript component in place which handles all of that. To debug your view is a little tricky at the moment. If you're running KNIME from an SDK in debug mode a debug.html is generated in which all components are present and no dynamic injection of code happens, however if you are running a regular KNIME product this is not the case. I think you have two simple options.
Use alerts for debug output and remove them when your view is ready.
Try to include Firebug Lite as an external library. You then have a console and element inspector in your view. In my experience this solution works for simple views, but is not always very stable.
I am also working on a series of blog posts about the Generic JavaScript view and the JS views in general. I will post the links here, once they are published.
I would like to add an idea to this "Feature Request" post on the "Generic JavaScript View":
It would be great if this node would also have a "Table Out port".
As far as I understand this request is technically difficult to implement, as the content of the "Table Out port" has to be managed by Java code. Therefore my suggestion is to combine the existing "Generic JavaScript View" node with a "Java Snippet" node. I guess it is not that easy to accomplish, but for us this would be of extreme value!
After a few weeks of experimenting, I must admit that the complexity of this node seems to be quite overwhelming for the non-IT specialist. It just appears to be me that the Generic JS View node may currently be less suited for experimenting with code than for putting already working code into production. Instead of forcing my workflow into KNIME, I've decided for now to abandon this node in favor of a combination of VS Code and a browser in developer mode for coding D3 and Vega views. Nonetheless, I am looking forward to any further developments of this node as well as any documentation of its uses.
I am also working on a series of blog posts about the Generic JavaScript view and the JS views in general. I will post the links here, once they are published.
Any news on that? I startet looking at the generic javascript node this week and was surprised how bare the development infrastructure is. No console, just alerts. Where is the joy of code completion (I am a generalist and can hardly remember all the apis of my tools)? How about some best practises with that node?
Any news about further development of Generic JavaScript View node? I am really waiting tutorial for extending features of generic javascript view node.
Thank you.