In most trading applications there is a requirement for a rich user experience. If the back-end works but the UX looks like a dogs breakfast the system will not be well regarded. Typically within a trading system such as an OMS or EMS there is a blotter with drill down and a form based order entry paradigm.For a C++, Java, C#, (your preference here) application there is usually an implementation where creating a form instance uses one of many constructors, such that the form can be pre-populated with appropriate information. Take an example of a blotter with a column containing a button with "Sell this position" for long positions. If the user clicks on the button then it would make sense for a constructor to pass all of the information needed to the form, with the form only really acting as a "are you sure?" (modal) dialogue. An alternative constructor may be called when the user clicks on a menu item "create new order", where the amount of data passed would be drastically reduced versus the example above.
By using JSON we can send different payloads and have the "constructor" selected dynamically. Of course, this could be done in a number of other ways such as queue up constructor on the server for the form to collect, pass the constructor variables in the URL called in window.open(..). I think this method is slightly less clunky, although not exactly perfect...
Within a JavaScript/HTML5 application one way to implement an order entry form is to create a new window (pop-up or new browser tab) that represents a specific web page. Since an HTML page does not have a constructor in the same way that a C# form does, this presents a challenge which is overcome (with a few quirks) by the postMessage method. The HTML5 page acting as a form has to then receive the message and process it.
The challenge is that if you create a new browser window (form) and then in the next line of code execute a postMessage call to that window the message may not be successfully received. Why? The "form" is created asynchronously so it may not be in a ready state to receive the message. This is the gotcha!
As such, you have to work within this by having the following:
As such, you have to work within this by having the following:
- Main application creates instance of form
- Main application queues up the "constructor" variables
- Main application creates listener for a form postMessage event
- Form has function receiveMessage to process received JSON
- Form, after starting, fires the specified event back to the main application.
- The main application listener can now execute postMessage to the form which is now able to process the message
- The form then has to process the contents of postMessage to which it already has a listener.
By using JSON we can send different payloads and have the "constructor" selected dynamically. Of course, this could be done in a number of other ways such as queue up constructor on the server for the form to collect, pass the constructor variables in the URL called in window.open(..). I think this method is slightly less clunky, although not exactly perfect...
Comments
Post a Comment