Friday, 26 November 2010

hiJump - Why CQS?

One of the most important aims of hiJump was to try to deal with the issue of communication between the browser and the server. We will have all come across the following pattern of communication:
  1. Browser requests page from server (get request, full page refresh)
  2. User fills in form
  3. Browser posts data to server (post request, full page refresh)
  4. Server finds issue with data and returns same page as the get request in step 1 but with a message describing the problem
Now this is very standard but not very nice. Why is it not nice? Well you have 'gets' returning html and you have 'posts' sending data (in effect a command) which also returns html. Yuck.

Now this sequence just about hangs together in an html interface which is not ajax based but it starts to cause real problems in an RIA (Rich Internet Application - AJAX based UI to you and me).

Take a look at this example of flow in an RIA:
  1. User clicks on a button to open a modal window (we are talking jquery modal here)
  2. An ajax get request is sent from the server for the content of the modal window and it is displayed
  3. The user fills in the form and clicks OK
  4. An ajax post is sent to the server
  5. The popup is closed
..... What happens if there is an error\validation error on the server??? This is the crux of the problem. If we are rendering html from our post requests, the return from our post needs to tell the UI to either close the popup (succeeded) or render the return from the post containing the form and the message back into the popup (failed). This is hard, horrible, non-consistent, non-intuitive stuff and you can imagine how easily this is abused over time in the code.

So, instead of posts ever returning html, they alway returns a json object containing only the following data:
  • Success\Fail flag
  • List of failure reasons if fail
  • Id of generated entity if success and the post asked to create something
  • List of domain events on the server which were fired during the execution of the command
If there is a failure: the UI can handle it in a consistent way providing a nicely formatted list of reasons in a modal window and stop execution at this point.

If it is a success: the UI can show the list of things that happened and can continue on its way and close the modal window. Or in the case of a 'create' can go ahead and load some more html using the ID returned

This works out quite nicely for the following reasons:
  • You do not have to do the old 'viewstate' type work of making sure people do not lose what they have entered if there has been an error. What they entered is still sat there and they can edit it and try to press the button again
  • The UI is controlling the application flow not a combination of the UI and the server post responses
  • All browser\server communication can go through this consistent process leading to much greater consistency in the code
In my next post I will be running through some fundamental requirements around domain modeling etc needed to make this work

2 comments:

  1. Very Nice !!
    We all appreciate with your post.Keep Posting...
    Thanks for sharing.
    Motorola WT4000/WT4090 Cases

    ReplyDelete
  2. Really the blogging is spreading its wings rapidly. Your write up is a fine example of this.It also cleared my doubt on using Rich Internet Application.
    sap support pack upgrade

    ReplyDelete