Data binding is one of the most powerful features of ASP.Net and Visual Studio. You can literally create an application with controls that are data bound to a database with only drag-and-drop and using simple wizards. However, with AJAX features your web application could refresh just its data instead of the whole page. Visual Studio does not offer much support for these more advanced features. This article will explain how to use Backbase data binding in combination with Visual Studio data binding.

Prerequisites and Intended Audience

Backbase Prerequisites

• Backbase Client Framework
• Intermediate level experience with the Backbase Client Framework

ASP.Net Prerequisites

• Microsoft .Net Framework v2.0 or higher
• Microsoft Visual Studio 2005 or similar
• Intermediate level experience with ASP.Net

Local vs. Remote Data Binding

In general, two approaches are available to data binding: local and remote.

Local Data Binding

With local data binding, you make sure that all the data that the user is able to see in this particular context is already available on the client (with Backbase, this is typically in XML format). Using data filters, the user may be limited to viewing only a small part of that data at the time, though all data should already be available in the browser. The client-side application code selects the data to be displayed from the client-side dataset.

The advantage of this approach is that users can get immediate feedback on their filter selection. For example, think of a slider to select only hotels in a certain price or quality range. Local data binding will result in the best user experience for small datasets. Unfortunately, this situation is not that common. The data filters are most necessary with large datasets, where the initial loading time of the page/application may become too much of a hassle for the user.

Remote Data Binding

With remote data binding, the visual controls/widgets are on the client side (within the browser), but the dataset remains on the server. Only the data that needs to be shown is available on the client. This is the most common solution for applications that use paging to show only small parts of the dataset. It is then up to the developer to use a simple pager or a more advanced solution like the liveGrid, though the concept remains the same.

The biggest advantage of remote data binding is obviously the short loading time. Only a small part of the data needs to be loaded. The disadvantage is that for every data refresh, additional client-server communication is needed. This could result in a slightly sluggish data refresh, even though it is still faster than in traditional web applications where the whole page would be refreshed. In the case of using the slider as a data filter, it will not work well, since the user will expect an immediate response while sliding.

Local Data Binding Example Application

We must first create an ASP.Net page that is using the Backbase engine: LocalListGrid.aspx.

For this example, we use an <asp:XmlDatasource />, because it is simpler to distribute, but you could just as easily use an <asp:SqlDatasource /> and link it to your own database tables. For local data binding, the <asp:Repeater /> is our key component. We use it to iterate over the dataSource and generate the desired page.

We have two options:

1. Use the <asp:Repeater /> to generate the whole <b:dataSource /> content that we will bind (client-side) to our widgets.
2. Use the <asp:Repeater /> to generate the visual controls/widgets, with the data as part of the widget.

A simple example of the second option would be to look at a table as a widget and generate all rows and cells with the data as content inside.

It this example, we go for the first option. It has the advantage that it can use the full Backbase data binding concept, with paging and so forth. Note that you may need to use the second option for Backbase widgets that do not yet support data binding, such as menus.

Our LocalListGrid.aspx file would look like this:

Additionally, we use the following local XML source file called movies.xml:

The LocalListgrid.aspx Explained

We want to use the powerful ASP.Net data sources. In the example above, we usec the <asp:XmlDatasource /> and simply loaded a data XML file:

<asp:XmlDataSource ID="contacts" runat="server" DataFile="movies.xml" />

Next, we define the Backbase listGrid widget:

Note two things here:

1. Do not let the fact that we use a server-side XML Datasource and a client-side XML Datasource confuse you. We could just as easily use an <asp:SqlDataSource /> server-side and create the client-side XML datasource using its data.
2. We have the <b:dataSource /> inline here in the <b:listGrid /> for convenience, but it could be anywhere in our page and linked using the dataSource attribute.

As part of our listGrid, we specify the colomns. The select attribute on each column determines the value from the dataSource that we want to show in this column.

Finally, we add a pager for the listGrid:

Since we are using a Backbase dataSource here, the pager and listGrid are smart enough to show only the desired records on one page, and when we iterate through the page, update the data from the client-side dataset!

Remote Data Binding Example Application

For clarity, our second example is almost exactly the same, except that we will use remote data binding.

The remote data binding example uses two files: RemoteListGrid.aspx and RemoteDataSource.aspx.

RemoteListGrid.aspx

RemoteDataSource.aspx

The RemoteListGrid.aspx Explained

With remote data binding, all the data is retrieved by additional client-server communication and they are all initiated by the client. That is why our page with the listGrid on it no longer needs the server-side dataSource defined, the repeater, and so forth. We simply have a page with the listGrid, pager and – very important - the client-side dataSource definition:

In this example, the e:behavior attribute tells the Backbase Client Framework that this dataSource is remote, the url attribute tells it where the data can be found, and the dataSelect attribute uses XPath to select the relevant data from our XML response.

It is important to know that Backbase is using a small communication protocol for remote databinding. You should check the Backbase documentation for details. Here we only focus on what is interesting for our example: page numbers and totalRecords. Obviously, remote data binding is mainly interesting for large datasets that are often shown using paging. In every request for data, the client passes the page (or data chunk) that needs it to load. In the response, the server passes the total number of records to enable the client to show how many pages are available, and enables/disables the next page buttons, and so forth.

To retrieve the data, we created a simple ASP.Net page (RemoteDataSource.aspx) without controls on it or code behind the file. This is just a simple file for loading the XML data and iterating over it using XPath, and a foreach loop to create the correct response XML document. At the end, the totalRecords attribute is added and the XML is returned to the client with a simple Response.Write.

Summary

In this example, we have shown you the concept of Backbase data binding in combination with ASP.Net. You can choose between generating local data using ASP.Net data binding and remote data with paging using an XML response produced by an ASP.Net page.