Normally, ASP.Net applications are typical Multi Page Interface (MPI) applications. However, with some small adjustments, it is rather simple to create a single page web application using standard ASP.Net components. For a technical explanation of the inner workings of the required adjustments, please read the Backbase & ASP.Net tutorial.

In this article we will show you how to integrate basic ASP.Net components in a Single Page Interface (SPI) application layout.

Prerequisites and Intended Audience

This example is intended for anyone interested in learning more about developing Backbase applications in combination with ASP.Net. It assumes you have read and understood the Backbase & ASP.Net tutorial. Familiarity with the SPI model, Backbase widgets and client-side event handling using Backbase XEL are also required.

Backbase Prerequisites

• Backbase Client Framework
• Intermediate level experience with the Backbase Client Framework
• Familiarity with the SPI model, Backbase widgets and client-side event handling using Backbase XEL

ASP.Net Prerequisites

• Microsoft .Net Framework v2.0 or higher
• Microsoft Visual Studio 2005 or similar
• Intermediate level experience with ASP.Net
• A compiled version of the Backbase ASP.Net Connector

For more information on the SPI model, please read the Technical Overview.

For more information on event handling, please read the Application Development Guide or the XEL Keyboard Events tutorial.

Creating a Basic Backbase SPI Application

The first thing you need to do is create the ‘main’ page. This is the page that will be sent to the client initially and the page that contains the code to load the Backbase engine. It should look something like this:

If you check the code above, you can see that it does the following:

• Loads the Backbase engine;
• Loads the basic CSS file;
• Includes three additional files: one for the Chameleon skin for our Backbase controls and two for changing the form post method from an MPI-style (where the whole page is submitted) to SPI-style (where the post is done asynchronously without refreshing the whole page).

Next, we must consider the main layout of our SPI. Let’s assume that we want to have two areas in our SPI: one for a navigation list and one to show the details of the selected item. In our script tag, we add a panelset:

For now, we include this in the main page, because it is such a simple example. If the layout / panelSet is more complex, we recommend creating a separate page and including it with the xi:include element.

So far, we still have nothing that makes it SPI. So let’s create two more ASP.Net pages that we put in the two panels. Since these pages will have to behave (render and post) as parts of an SPI application, we must create them using the SPI template that is part of the Backbase .NET Connector. The easiest approach is to copy the files and rename them. Remember to rename the classes, too.

The ASP.Net pages that we create using the template will not derive from the normal System.Web.UI.Page class, but from the Backbase.Net.Page class. This superclass will make sure that all IDs will be unique throughout all the pages that compose our SPI applications, whereas in normal ASP.Net, the IDs only have to be unique within a single page.

This Backbase.Net.Page class lives in a separate assembly that is part of the Backbase .NET Connector. In order to compile, we must add a reference to the Backbase.Net.Connector.dll to your web project.

The examples used in this section can be found in BasicsExample.aspx, BasicsNavigationPage.aspx, and BasicsContent.aspx.

Using User Controls

You may have noticed that the approach described in the example above has a serious disadvantage: Visual Studio no longer recognizes our SPI pages (based on the template) as ASP.Net pages and we cannot use its visual designer.

Fortunately, a simple workaround is available. Instead of creating ASP.Net pages based on the template, we just create normal ASP.Net user controls. We load these user controls using an intermediate page (getUserControl.aspx) based on the SPI template. The code of this intermediate page is quite simple:

Now all we have to do is to pass the user controls files as a parameter to the getUserControl.aspx file. Since we have normal user controls, the designer functionality works again (at least for the non-Backbase code and controls).

Building your SPI application using user controls is preferred. This is not only because of the Visual Studio advantages of using normal ASP.Net user controls, but also because it is conceptually correct. An SPI application can be logically divided into components that can often be represented as user controls. It also makes your code fragments reusable in normal ASP.Net applications.

The examples used in this section can be found in UserControlsExamplePage.aspx, UserControlContentPage.ascx, UserControlNavigationPage.ascx, and getUserControl.aspx.

Communication Between Your SPI Controls

In MPI ASP.Net applications, all controls on the page are managed by the server, and we can therefore communicate easily from one to the other, often just by name. On the other hand, our SPI consists of multiple ASP.Net pages and the server is not aware of the relationship between them. Typically, we must write some more intelligent code on the client.

Let’s take the examples from the previous sections and extend them a bit. Since this is an SPI application, we create a small controller that will refresh parts of the page. We assign this role to the upper panelSet by attaching an event to it that will refresh the content pane (with CommunicationContent.ascx):

On the leftmost panel, we add two tree components: a Backbase tree (in usercontrol CommunicationNavigationControlBB.ascx) and an ASP.Net TreeView (in usercontrol CommunicationNavigationControlNet.ascx). What we want to achieve is that when the user (double)clicks a tree node, the controller is informed about it, and it will update the details pane with information about the selected tree node.

Backbase Tree Control

The code for the Backbase tree control is relatively simple, because all logic is on the client. We add a dblclick event to it:

This triggers our controller’s TreeSelectionChange event and passes the label property value of the selected tree node with it.

ASP.Net TreeView Control

The approach for the ASP.Net TreeView is quite different. We can use the standard ASP.Net method and just hook some code into the server-side SelectedNodeChanged event. But we are on the server and we want to inform the client-side controller about the selected node change, where the server is not even aware of its existence!

The Backbase.Net.Page class has a method called DispatchClientEvent that will let us do exactly this. This event is dispatched in the context of the TreeView control, but we can use the elegance of event bubbling here, since our controller (the panelSet) is an ancestor of the TreeView control. As a result, the only line of code we have to add here is:

Summary

In these examples, we showed you how to create your own SPI application using Backbase and ASP.Net. We showed you the brief concept, the way to use user controls and a generic mechanism on how you can communicate between your SPI components and how to use a mixture of Backbase and ASP.Net controls.