Dyalog Forums

Pierre, did you evaluate WebView2 and CEFSharp before deciding to go with DotNetBrowser? Were you able to get either of them to work?

Well, with Michael Hughes it seems doable and easy but I don't know how he is doing it. Currently, we are just requesting the variable as a big JSON file when needed and it is parsed according to many data-xxxx properties at the same time. If one could maintain a JSON variable to be the same in the APL WS and the Web app that would be enough for us.

As it's been mentioned before early adoption was very difficult.

- No https METHOD in callbacks
- Outdated CEF version containing critical bugs and lack of support for newer copy and paste functionality.
- APLCore crashes initiating HTMLRenderer
- Lack of documentation on required runtime redistributable
- No user ability to update CEF in general.
- No ability to check if the URI has been changed on the client by the SPA (single page app)
- The control always reloaded all resources when a URI fragment was changed by JS. This was very expensive and time consuming with large JS frameworks. I have not checked how this works in recent builds.

Some of these have been addressed and we are using the control for one small use case now in runtime.

Pierre, did you evaluate WebView2 and CEFSharp before deciding to go with DotNetBrowser? Were you able to get either of them to work?

WebView2 did not exist at the time we tried and we were not able to make work CEFSharp. We tried also https://www.essentialobjects.com/Products/WebBrowser/Default.aspx but it was bugging with Dyalog at the time we tried it. DotNetBrowser worked well with Dyalog with the release we tried at the beginning, but they upgraded the way to interface with their dll's that is no more compatible with Dyalog and we need a companion dll now to start the application. But once the application is started it is very stable and working well so far for us.

One of the main things CEF and WebView2 do I think (and I assume DotNetBrowser too) is provide direct access to the DOM from the host app. Thus I could do something like (pseudo code):

      e←Document.GetElementById 'MyDiv'
      e.InnerHTML←blah blah blah

You can't do this with HTMLRenderer. All actions after setting the HTML or URL are instigated in the browser, not in APL. I can see how I could roll my own using WebSockets (supported) or SSE (not supported by Dyalog I think).

Pierre, is this a feature you use in DotNetBrowser, and have asked Dyalog for?

PGilbert wrote:If one could maintain a JSON variable to be the same in the APL WS and the Web app that would be enough for us.

When you say "JSON Variable" I'll assume you intend that an object graph should be kept synchronised on both sides of the fence: on one side you have a nested array (or more generally a tree of namespaces containing nested arrays) and on the other side you have a "javascript object" (or at least the subset which could be serialised as JSON).
First of all, let's remember that Javascript and nested arrays have a different domain: in Javascript there are no arrays of rank greater than 1, for instance. So let's also assume that only the subset of nested arrays which can be turned into JSON using the []JSON primitive will be supported.
A trivial implementation would marshal everything for every change. This would be hardly noticeable for small objects but unbearably expensive for large trees. Notice that this is already possible using variable triggers on the side of Dyalog and proxies (https://developer.mozilla.org/en-US/doc ... ects/Proxy) on the side of Javascript. There are, indeed, Javascript frameworks based on proxies.
In case one cared about performance, one would need to send only deltas to changes. Proxies and triggers, once again, could be used to build a prototype where only deltas are exchanged, as far as I understand the problem.
Notice that, in general, Dyalog and the Javscript engine of the HTMLRenderer have separate and independent execution threads and they could both change the same element of the same array at the same time in different ways and the protocol would have to decide what to do with conflicts (in the same way you have to deal with conflicts when you merge code coming from different origins).
Once you have the data magically transferred from Dyalog to Javascript (or vice versa) you'd still have to have a mechanism to inform the rest of the application that a change has occurred. So, I imagine, you'd have to subscribe, on both sides, to callbacks, unless you expect a certain direction of flow to be preferential (like from Dyalog to Javascript) in which case you'd be ready to manually inform you web app that the data has changed and that something should happen. But if this is the case, I guess you'd be better off sending the data along with the method invocation that causes the refresh of the GUI.

Is this along the lines of what you had in mind?

Pierre, is this a feature you use in DotNetBrowser, and have asked Dyalog for?

Yes, you can reach the DOM object properties from APL if you want and it is working fine with DotNetBrowser and Dyalog but we have opted instead to exchange a large JSON file that is parsed in APL and HTML so it will be easier to switch back to HTMLRenderer later. Also when we are developing the HTML/JS code (with Visual Code or other) it is easier to set up a server in APL that will answer the request for the JSON file and be able to develop the code with this tool otherwise it is not possible when writing directly to the DOM object properties.

Is this along the lines of what you had in mind?

Yes, but once you explain all the trouble it is I would prefer to continue doing what we do now.

paulmansour wrote:

      e←Document.GetElementById 'MyDiv'
      e.InnerHTML←blah blah blah

You can't do this with HTMLRenderer. All actions after setting the HTML or URL are instigated in the browser, not in APL. I can see how I could roll my own using WebSockets (supported) or SSE (not supported by Dyalog I think).

In addition to implementing it using WebSockets (which would be a major pain), v18.0 introduces a shortcut: http://help.dyalog.com/18.0/#GUI/MethodOrEvents/ExecuteJavaScript.htm?Highlight=executejavascript

While not the same as working directly on the DOM (the way you used to be able to do with the Internet Explorer COM control), you can build simple Javascript snippets and submit them for execution. The syntax would be very similar to what you'd do in Dyalog (if you exclude dotting over arrays of objects and so on). The one thing that's missing in v18 (and that might be coming in 18.1) is a way to know that the DOM is actually ready: at the moment once you set the web app in motion, you have no way of knowing if your JS libraries have been loaded and if the DOM you expect to interact with was built. You could roll it on your own by having the web app POST a request to the APL side of the app claiming that it's ready. But we are talking about building a protocol to describe a bidirectional asynchronous Remote Calling Procedure mechanism. Eventually, the fact that the two execution engines (APL and HTMLRenderer with its Javascript VM) are indipendent and fully asynchronous is likely to bite you. But with a bit more support from the interface you might be able to eliminate the simplest of the issues. Which is why I asked Dyalog to help us at least with the bit about knowing the the DOM is ready.
For the record, users of CEF/CEFSharp too sooner or later come across this problem (a random issue: https://github.com/cefsharp/CefSharp/issues/1231).

If the method ExecuteJavaScript could return the answer from JS a lot could be done, like getting/setting the properties of a DOM object.