The WidgetSet Standalone Simulator

A Standalone Simulator

This week, one of my task is to determine whether the simulator can be implemented as a standalone simulator, and also able to be called by any HTML/witty application to use it. As suggested by my supervisor, there is an example of widget set in the witty example, which has similar concept on this. After analyzing and did some research on the widget set, I manage to implement the widget set to be a standalone application and also uses by other witty application.

However, there must be a communication between this widget set and the main witty application. I found that the example of witty itself is not enough as it does not demonstrate how these widget set that is hosted by other witty application can communicate with another witty application. Thus, I looked through the JavaScript example, and I found that the usage of WSignal is not sufficient to communicate these widget. Meanwhile, from the browser console, I manage to figure out that the JSignal can do the job as it uses a Wt.emit() signal. The communication between the widget set and the main witty application can be done using Wt.emit() from the widget set to the host witty application. Meanwhile, (widget set ID).emit() can be used to communicate from the host witty application to the widget set. All I have to do is to make a widget container and change its ID in the widgetset and uses this ID for JSignal emitting from the host witty application. Besides, after numerous attempt to fully understand how witty widget set and host witty application work, I found that the calling of widget set will actually replace all the widget contents in the host witty application.

The Web Worker Issue

As I experiment through the widget set, I would like to highlight that the usage if web worker is impropriate for widget set. The JavaScript Web worker function actually loads local files, unlike require() from witty API enable loading of JavaScript file from widget set server. Therefore, if I use the web worker in widget set, and then called by the host witty application, I would need to include the web worker file in the host witty application file as well.

The usage of web worker can actually import execution files. The usage of require() actually cannot fetch the code directly from Github as the MIME type of the file is plain text and will trigger an execution error.

The WResource of WidgetSet

Just like the web worker function, usage of WResource also calls from the host application server. Thanks to my colleague Sumia who give me an idea on how other witty application can call the WResource from other witty application. I figured out how to solve this WResource issue just be calling back the widget set server address using WClient.

The VM JavaScript

While solving the communication issue of widget set and host application, I also discovered that doJavaScript() from witty API actually stores the code to the virtual memory (VM) files, which can only be used for execution of JavaScript function. Unlike the require(), which includes the JavaScript file, and the functions declared can be called by any widget. The host application can actually calls the function declared in the JavaScript file but not the function declared using doJavaScript().

Currently, I am developing a widget set that calls the Simulator function without the worker, and solving for the Json parsing to the Simulator using Witty API.