HTML5 postMessage as a "form" constructor - gotcha!

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.
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:
  • 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 I think this method is slightly less clunky, although not exactly perfect...