DataSet, only living on the client. By using Abstract Programming, you can eliminate unnecessary postbacks, and realize the possibility of an application program running unplugged.
The methods used in this series are intended to create solutions that will run in all browsers. These examples were tested in both Internet Explorer and Netscape, but all the development was done with Internet Explorer. The examples and exercises were developed with the .NET 2.0 Framework using Visual Studio 2005 and SQL Server 2005, but the concepts of Abstract Programming are independent of any particular technology. This three-part short series was created using the techniques described in this series.
The biggest mystery, for .NET web application developers, is how to create an autonomous application program. How can a web application not need to get data from the server to perform its functions? In other words, is it possible to function without doing a postback to the server? Yes! It is, but, of course, at some point, you need to get data from the server, but it can certainly be cached on the client machine, and without the need to add special components such as Java, ActiveX, or AJAX. When you think about it… going to the server, every time you need data, is like keeping your remote on top of the TV. This part describes a model of abstract programming that will reduce, and possibly eliminate, the need to do a postback to the server.
Breaking Through the Other Side
The Einstein-Rosen Bridge design models after several simple design patterns and several basic concepts. It is also the most advanced model of Abstract Programming presented in this three-part article. The first concept is that a data table is stored on the client. The second concept is that the data table only needs to be replaced when the data it represents has changed. Just what does this buy you? Everything! Now, you no longer need to go to the server for the data table, so the processing time is much faster. In fact, you could access the data and run your application unplugged. Hmmm…
Here is How it Works
When the web app starts up, it compares the date code of its data table on the client machine, to the date code on the server. If the date code is different, it downloads the latest datatable.js and datecode.js. It then begins using the latest data table. The data table, of course, is a collection of data rows, and is equivalent to a
DataTable in a
DataSet. The date code represents the last time the data table was modified on the server. More accurately, the date code represents the last time the database was changed, which will affect this particular data table on the client.
Worming Through the Rosen Bridge
Authoring a datatable.js File
Here is the really tricky part… When changes occur to the database that affects the web application's data table, a new datatable.js is generated, then a new datecode.js is time stamped with
DateTime.Now.Ticks. The next time the web app starts, it compares its date code, and if it differs, then it gets a fresh copy of datatable.js.
Other Points of Interest
Components Used in Rosen Bridge
DScript of CStorage184.108.40.206.js
CDataTable and populate its data table members. Here is a typical datatable.js file:
CStorage1_dt = new CDataTable();
CStorage1_dt.sql_id = 0;
CStorage1_dt.datecode = '632818039432854577';
CStorage1_dt.columns = 'row_id' + delim1A + 'col1' +
delim1A + 'col2' + delim1A + 'col3';
CStorage1_dt.rows = '0' + delim1A + 'alpha' + delim1A +
'baker' + delim1A + 'columns';
CStorage1_dt.rows = '1' + delim1A + 'A' + delim1A + 'B' + delim1A + 'C';
if(CStorage_onloads != null) CStorage_ontable_loaded('CStorage1');
DScript of CStorage1_datecode.0.0.0.js
This DScript is the datecode.js, and is also authored by the server control "
CStorage". This DScript is a date code of the value
It looks something like this...
if(CStorage_onloads != null)
this.rows = new Array();
this.columns = "";
this.datecode = "";
this.isDirty = false;
The heart of this particular Abstract Programming model is CStorage.cs. It is responsible for authoring both DScript files (CStorage220.127.116.11.js and CStorage1_datecode.0.0.0.js). It converts a .NET
DataTable object into a DScript file, and it maintains a simple database that stores the latest date codes for the data tables it maintains.
This SQL Server 2005 database stores queries, and date codes associated with these queries, in a table called dscript (how appropriate). This database table (dscript) is only accessed by CStorage.cs and should not be accessed directly. The date codes in the table "dscript" are the date codes that you compare with the date codes on the client, to confirm that the client has the latest data table. Please note again that there is one date code associated with each data table.
Data table dscript:
A Quick Demo of CStorage in Action
First, download and install the projects in the appropriate location in accordance to the readme.txt file supplied in the extracted Abstract_Programming.zip file. The readme.txt file will spell out the requirements and supply you with some quick installation notes. After installing, open up the solution "Unplugged" and make "TestControls" the startup project. Next, in the CStorage folder, set "default.aspx" as the default startup page and run the page in Debug mode by pressing F5. You should see three links that open three different .NET WebForms. Today, we will be looking at Data_Entry/Default.aspx and Real_Time/Default.aspx.
After changing col1, col2, or col3, click the Update button. When this happens, you will update, on the server, the database (Database.mdf) and create new datatable.js and datecode.js files. Use the web app Real_Time/Default.aspx to see these changes in real-time.
Use this page to see the results of changes made to Data_Entry/Default.aspx. These changes happen in real-time without the need for doing a postback to the server.
Demo Database - Database.mdf
This database is used for demonstration only, and is not part of the Rosen Bridge model. When data changes in this database, we update the CStorage.mdf database with the latest date code, and the Rosen Bridge will author new datatable.js and datecode.js.
In case it is not too obvious, it is important how you name your DScript files. Why is this important? Because you need to understand what groups will be using your DScript. If you want everyone to view the result of the DScript the same way, then you need only one DScript file. By the way, this is the case of the CClock exercise in Part 2. But in this scenario, where you are creating DScript that be unique for each user, it is necessary to choose your naming convention carefully. What does this mean exactly? This means that you will need to make your DScript file name include something like the user ID, or group ID, to assure that one user will not overwrite the DScript created for another user. Also, consider using the table name or table ID as part of the DScript file name.
Using the source
Download the Zip file, then extract the files into your C:\Inetpub\wwwroot as per the instructions in the Install.Readme.txt. Follow the instructions to setup and use the source code and to setup the browser.