Posted on MSDN, by Dino Esposito, “Single Page Interface and AJAX Patterns.”
What is it? From the article…
Single-Page Interface Model
To take full advantage of AJAX, you need to have all of your features, or at least most of them, in a single page. This is known as the Single-Page Interface (SPI) model. In the SPI model, all browser interactions with a Web application take place within the boundaries of just one page. This approach is revolutionary for the Web, but it is nothing new for Windows® and desktop development. In the end, the SPI model is just like having a Windows application with a main (and unique) window.
There are a number of frameworks that work this way (especially in the J2EE) camps. For all but the simplest of applications, all suffer from the complexity of either extreme-componentization or from an extremely complex single page implementation.
In the SPI model, the main page is a combination of visual elements that can be loaded, updated, and replaced independently (see Figure 3). In this way, the entire page doesn’t have to be reloaded following a user action. At any time, only visual elements and content that is relevant to the current stage of the application is displayed. Everything else is hidden; it will show up as soon as there’s any need for it in the application’s flow.
Instead of having multiple pages, a single page contains all of the application functionality. Although not impossible to create a large system utilizing this pattern, it has several downfalls which you should be aware of before jumping in…
- You must create a hosting architecture — you won’t want to load and instantiate every component on the page (even if they are hidden) every time the page is loaded (remember, this happens when the page is first loaded, and for any “update panel” style UI you might use. So, you’ll be forced to create a system in which components are dynamically constructed based on demand.
- Furthermore, the dynamic nature of the hosting pattern may make handling events and AJAX callbacks more complex.
- If you take the approach of putting everything on a single page, and limiting the amount of componentization that you do, you’ve created a system which is only practical for only one or two developers to work on the UI at any one time. Often, this is not practical and will slow development down.
- Of course, it may break the back button behavior (the ASP.NET Extensions Futures may help with this though).
Dino continues and provides a good explanation of how one could continue to preserve the user’s concept of the “back” button in the web browser using the window.location.hash and the onload event in the browser.
The timeout pattern he suggests though is less than ideal. Although it does prevent a browser from potentially hammering the web server when the user has left the browser, it comes at a cost of usability. He suggests that a modal message box is displayed after a period of time, asking if the user wants to continue. Unfortunately, depending on the nature of the web site, once the timeout has occurred, any session data associated with the active user has also likely timed out. Even if session state has not continued, it feels like a better solution is needed.
Although he suggests that keyboard and mouse activity monitoring might be “heavy”, I don’t think there are really any better, more user friendly options if you’re concerned about the impact of requests on your web servers. Here is a web page that details the various time out options and provides a demonstration of how to use mouse movement to reset a timeout automatically.
.
Surely the simplest and best solution is to just refresh less often when idle and buy a server that can cope with 1 refresh every 20 minutes from all the idle sessions? It might be worth making sessions last longer (session state can be dumped into a database anyway, and hard disks are cheap) so that refreshes can be more infrequent, but that’s a minor detail.