I have been told, many a time, that I may not be perfect, at least when it comes to remembering things that I am told. This disconcerting truth is provable in that I am often told a date or time when I need to be somewhere or do something, and just as often I forget where I am supposed to go, or what I am supposed to do.
As frighting as my own imperfection, I am fairly certain that I am not alone in my foible. It is likely, that you too suffer from some sort of deficiency when it comes to remembering the exact details of every single coverstation you've had in the last say 10 years.
But there is a remedy to all this ailing, in fact there are many very viable remedies, all the way from a paper date book to the newest shiniest smart phone. These tools exist to fill in the gaps in our memories, and help keep us on track with the tasks that continually beset us.
From what I can tell about the last post's examination of the world of Banks and balance books, I really need to have some tool with which the server and the client in my fictional value slider world can track a common understanding of their conversation. But before I go too far down that path I really should come up with a problem set a little more complicated than a single value slider, so here it is.
I want an AJAX driven form that tracks the following data for the purpose of recommending a personal transportation plan:
This will give us more data points to track, and with that a better likelihood that, without some sort of strategy, the client could get out of sync with the server.
Some of you may be wondering, aren't there methods to deal with this problem already, surely this can't be something that slipped by Microsoft when they put together their AJAX framework. And you'd be right to wonder, because if you keep things simple and use standard Microsoft controls, like wrapping the entire form above in an UpdatePanel, then everyting would work fine, and problem solved. But its not that simple. There are times in the times when you may want to have finer granularity, and remember our problem is not when we let a control like the UpdatePanel manage the state of the UI, it arises when we take control of the UI to make it even more responsive, and separate it from the callback to the server.
To make my form above supper snappy for the end user, I'm planning to separate the UI from the postback to the server. I've set a benchmark of less that 200ms for the UI to update after user interaction, and unfortunately using the UpdatePanel control doesn't get me that level of performance with enough consistency.
Admittedly some of the constraints that I will be defining for my fictional example application are uncommon for most business applications, but the in this case I think it's fair to shoot for a high bar to evolve a pattern that should work for even basic asynchronous web applications
OK now back to where I was rambling. How to get a co-located snapshot of our applications state. From the point of view of the bank/balance book model, It seems that I need to have some way for both parties to have a copy of each-other's data. I know that in the real world it is not possible for this to occur in real time, however I think that from what I know so far, that If i had a way to pass the balance book (client state) to the bank (server) every time a change was made by the client, and correspondingly send a bank statement (server validated state) to the account holder (client) I would have a good chance of maintaining a synchronized state.
So how do I do that exactly? Everybody's new best friend JsON (note, there are actually lots of valid ways to handle pushing data from client to server and back again via JavaScript. In most cases JsON is an acceptable path, but one should always check out whether other possible data packing strategies are more appropriate for a particular challenge). JsON is a standard way of packing data for using in JavaScript driven asynchronous web. The data from the above form could be represented by the following string.
TransporationPlan { fName:MyFirstName,lName:MyLastName,nCars:2,nBikes:3,nTrips:7,mPerTrip:2,Plan:Bike More}
This tidy data packet contains our whole client or server state, and allows a very small request/response transaction to take place. For those of you who haven't spent time looking at how the HTTP Post works under the covers it might worth doing some digging especially around multipart/form-data. You'll see some very familiar parallels with the JsON approach to packing data.
Using JavaScript I can create a TransportationPlan object on the client, push it to the server and receive a validated copy back, but this really doesn't solve my problems. Even though a the client always tells the server everything it knows about state, and the sever always sends back what it knows, I think I see a big huge hole in this. What happens if a client sends 2 or more pushes to the server before it gets a response. What should the client do then? does it take the server's copy and overwrite the local changes? Or maybe the client stops listening for a response to an outbound request when a new request is made?
This is a place where I failed to really look at my existing model of bank /balance book model. The entire area of conflict resolution is really where I need to focus some energy both in observing some existing patterns, and in creating an idea of how incorporate those observations into my application. It looks like I've got a lot to cover in my next post.