Generating JSON Elements

As last week was mainly focused on searching and troubleshooting problems, this week was all about applying these techniques and getting tasks done. As I discussed in the previous post, I used HTTP redirection to load the program. What I added this week, is setting cookies to handle sessions, triggering the schematic editor from other part of the page, parsing and generating JSON file to be loaded by the JointJS editor.

First task was to handle multiple sessions at the same time. The plan at first was to use the session ID to distinguish between sessions. However, since the project archived is handled first and temporary folders are created before starting the application session, we used unique folder name for each session. And that unique key is sent to the application as cookie when the project is starting. For all subsequent HTTP requests, the server will first read the key value from the request cookies to determine which folder is to be accessed.

Next, I had to figure out a way to call a function that will execute some Java Script code for the schematic editor. The function will be called after a Java Script event is triggered from a different part of the code. The first implementation of the task was using JSignal to trigger a Wt function that will execute the required JS code. However, it did not work. All variables that we have defined in other part of Java Script cannot be accessed are not defined. The problem seemed strange because when referring to these variable from other functions (other than the one that is connected to the JSignal), they will work fine  and find these variables. I think JSlots could do the trick for us. However, we didn’t have to. We solved the problem in an easy way by using JavaScript functions that are called within the Java Script code. Since that task was fairly easy and direct, we took Witty out of the picture.

A picture of the schematic and code editor

Finally, the last (and most complex) task was to generate a JSON file to be loaded by the schematic editor. Before diving into the details, let me say that, as it is now, this implementation is not the most efficient, yet it provides great flexibility in manipulating the JSON file. Our schematic editor will be updated many times during the session. Some components might be added and others will be deleted. Whenever the editor is updated, a list of the current components are sent to its server. Hence, the server should check which components are added and which are removed. Then it should generate the code for the added components, retain the code for the ones that are not removed (including all there attributes, such as their position), and remove from the editor the components that are no longer needed. Developing and implementing the algorithm to this task took some time, but eventually, it worked perfectly. All processing, instantiating and removing components, this way is done at the back end. A complete JSON code is then sent to the editor to load it. The limitation with this method is that, as the file grows in size, more bandwidth, will be required to send it and receive it. The second option is to only send a list of the components from and to the editor and some of the processing will be done on the client side to remove and instantiate the components.

The process on this project will be put on hold for now. A different task is assigned to me and I’ll be working on that one. It is different than what I have been doing until now as the new task is related to embedded systems design.