OutPost: How I got the Idea

It is a novel solution. I got the idea, while I was developing the framework for a web site editor called UpFront in 2002, where the user designs his pages by inserting text, images, data lists, web forms and navigation menus on the pages.

The language was ASP (JavaScript) on the server-side and JavaScript on the client. I had two parallel frameworks to create data lists, web forms and navigation menus (one on the client-side and one on the server-side). The client-side framework was used when dynamically creating or updating the properties of a data list, web form or navigation menu in the editor (with heavy use of DHTML and XmlHttp calls to retrieve dataset in JSON - developed on top of JSRS). The server-side framework was used when rendering HTML on the first page load.

I found out that I could trash the client-side framework by calling an ASP page that returned the HTML and JavaScript needed over XmlHttp. This was a huge improvement i productivity, because I had one framework less to maintain and I could develop new "controls" faster.

This solution also gave me the advantage that I could gradually convert to C#-compiled code and I did so by calling a .NET web service over XmlHttp for the data list and navigation menus to start of with, and I still used a page (now an ASP.NET page) to render data lists and navigation menus. Now I could take advantage of the ASP.NET DataGrid for my lists, but in order to make it work properly I had to support the view-state and the server-events, so I examined the headers and the body of post backs to ASP.NET pages (using Fiddler and other HTTP debugging tools) and I was able to simulate it. So now I had my data lists and navigation menus rendered like stand-alone .NET pages with support for State Management, Server Events, Page-Level Caching, Page Fragment Caching, Session, Application and Data Cache. The HTML that the page generated contained the view-state, but I didn't have to return that to the client, since it's not used for anything on the client, so I stored it in Application together with the HTML. In that way I could compare HTML from request to request and didn't have to send more than necessary to the client. The view-state was combined with the form data from the client to make the request to the ASPX page.

So that's how I got the idea. As you can see I started out with Remote Scripting and DHTML (AJAX!). I moved away from that primarily to get productivity gains. OutPost is cross-browser compatible because it relies on ASP.NET controls that are cross-browser compatible. That also means that when you use OutPost on an up-level browser JavaScript will be transmitted on the first page load to take advantage of the capabilities in the client browser, and less HTML will be transmitted on post backs or no post backs will be necessary at all. So it will not be a screen scraping on up-level browsers. If the client browser is a downlevel-browser more HTML will be transmitted. In the examples in the demo project I have set the Page attribute clienttarget="downlevel" to force it to make a post back, but you can remove that attribute and no post backs will be made.