mh-z web-log

My ideal philosophy for Web application design is as follows:

The entire application exists on a single page, which loads once after the user logs in. All HTML is sent to the client at this point. All further interaction between the user (client) and the server is in the form of JSON data which is sent back and forth. This data generally doesn’t contain HTML or any specific formatting information; that was already sent over either in the form of HTML templates, or else rendered dynamically by Javascript code, which constructs specific widgets. For example, a textual screen with fields in specific places is sent as an HTML template, and the data for the template’s fields are sent as a separate JSON data block. Javascript on the client side is responsible for rendering the template and putting it up on screen. Certain fields in the template may reference sub-templates or more advanced widgets, such as sortable data tables, and the data, which was received through JSON, is rendered into the appropriate presentation and inserted into the template as needed.

As the user navigates from screen to screen, the hash portion of the URL is updated, enabling the browser’s Back button and bookmark functionality.

For an application with many screens, where loading all screens at the beginning before showing anything to the user would cause too much of a wait, the application can load sets of screens in the background once the initial set of screens is loaded and displayed.

A screen template may include more than just HTML with fields denoted; it may include Javascript code which is specific to rendering that screen. The code can then be eval’ed in order to add the requisite functions to the app’s codebase.

As a user is editing data, the browser should frequently send save-state information to the server, so as to prevent data loss in the event of a browser crash or connection-lost condition. On subsequent login, the user’s data should always be recoverable.

On the server side, the server is very data-centric and knows very little about the application’s UI structure. It just handles requests for data, and responds with it, given that the authenticated user has the relevant permissions. It has handlers which can respond with many forms of data. The server’s handlers are flexible and can respond to a single request which requires data gathered from many sources: this way, the UI’s data needs don’t need to be tied too closely to the handlers which satisfy them. In fact the term //source// would be better than //handler//. A true handler, on the other hand, may handle requests to update data.

To be continued…