Under the Covers - How It's Done
The sharing of DataWindow data across sessions is done using existing DataWindow.NET and ASP.NET features. The data to be shared across sessions are stored in DataStores that are, in turn, cached in the ASP.NET application's single instance of HttpApplicationState. The DataStores are indexed by the DataWindow name prefixed by "SharedDW_" in the case of shared DataWindows and "SharedDDDW_" in the case of shared Dropdown DataWindows.

For a given shared DataWindow, the corresponding DataStore is initialized during the first invocation of Retrieve of any DataWindow Control that has the specified DataWindow as its DataObject. The initialization includes an invocation of Retrieve on the DataStore.

Once the DataStore has been initialized, the ShareData mechanism is used to share data between the DataStore and the DataWindow Control. Subsequent invocations of Retrieve on other DataWindow Controls that has the specified DataWindow as its DataObject will trigger only the ShareData mechanism. The .NET concurrency services are used during both the initialization and ShareData phases.

The use of the ShareData facility of the DataWindow explains the restrictions on DataWindow Controls that make use of this Web application-level sharing of data.

Event Handling & Latency
In the WebForm deployment version of the DataWindow, the following events are triggered by user action on the client side:

• ItemChanged
• ItemError
• ItemFocusChanged
• RowFocusChanging
• RowFocusChanged
• ButtonClicked
• ButtonClicking
• Clicked
• DoubleClicked
• RButtonDown

How Client-side Events Trigger Server-side Event Execution
To execute the corresponding event script on the server-side, the DataWindow uses the ASP.NET postback mechanism. There's no one-to-one correspondence between an event triggered and a postback. In most situations, events and related data are accumulated before an actual postback. To give an example, suppose a user finished entering data in the edit column and clicks on an item on another row. This causes the following events to be triggered:

1. ItemChanged
2. Clicked
3. RowFocusChanging
4. RowFocusChanged
5. ItemFocusChanged

Postback in this case occurs only on the last event triggered, ItemFocusChanged. On the server-side, the five event scripts are executed before the DataWindow is finally re-rendered. Depending on the values returned by the event scripts, the entered data may be rejected or the focus change disallowed, the same behavior one would expect from a native PowerBuilder application.

When No Event Scripts Are Defined for a Particular Event
When user action triggers an event for which there are no corresponding event scripts on the server side, no postback occurs. For example, if the script for the ItemError event is defined (and no others), postback occurs only if the user enters invalid data.

Under the Covers - How DataWindow Event Scripts Control Client-side JavaScript Event Handlers
The WebForm version of the DataWindow is actually nothing other than a subclass of the DataWindow.NET WebDataWindow control. The client-side programming capabilities of the WebDataWindow are used to control the client-side JavaScript event handlers. Depending on what PowerScript (server-side) event handlers are defined, different client-side handlers are attached. The "PBDataWindow.js" file contains all these handlers. The choice of handlers to attach to each event follows the logic described in Table 1. Also indicated in the table is whether each handler will cause a postback.

The ClientEventXxy properties of the WebDataWindow have also been exposed should the need to override the ones in "PBDataWindow.js" arise. The names of the properties have however been changed - please refer to Table 2. The signatures of these handlers and the effects of their return values are documented in the DataWindow.NET references. You can also find this information in Chapter 3 of "Deploying Applications and Components to .NET" in the PowerBuilder 11.0 documentation.

This ability to override client-side event handler allow user-defined client-side handlers to circumvent postbacks according to user-defined criteria. For example, it's possible to define a client-side ItemChanged event handler that posts back only if the column isn't a radio button or checkbox - the event handler can do this by returning immediately on determining that the source of the event is a checkbox or radio button - on determining that it's not a checkbox or radio button, the handler should invoke the pre-defined handler (listed in Table 1).

An Example
Suppose you do data validation for some columns in ItemChanged. You don't want postbacks for columns that aren't validated by ItemChanged.

First, create a text file to contain the JavaScript function that will serve as the new event handler. Look up Table 1 for the function used as the handler for ItemChanged. You'll need to call this function in the function you're writing.

Next, look up the signature of the client-side event handler in the DataWindow.NET reference.

Your function should check whether the source of the events is the columns that need validation by the ItemChanged event. If so, invoke the pre-defined ItemChanged event handling function you found. If not, return without further processing (See Listing 1).

//Start MyScriptFile.js
function MyItemChanged(sender, rowNumber, columnName,newValue)
{
    if(columnName == "emp_id")
    {
    // The default function is invoked
      return PBDataWindow_ItemChangedReject(sender,rowNumber, columnName, newValue)
    }
    else
    {
    //do nothing
    }
}

Listing 1 Client-side ItemChanged event handler

In PowerScript you'll have to add some code to the constructor event of the DataWindow control in question. Set your JavaScript function as the client-side event handler for ItemChanged (see Figure 6).

Then, as the last step, deploy, remembering to add the newly created JavaScript source file to the deployment (see Figure 7).

Refactoring
An alternative to using client-side JavaScript to reduce postback is to change how your DataWindow handles events. Try replacing the functionality in these event handlers with the following alternative approaches:

• Clicked - avoid it entirely. If possible, use a control like a CommandButton and put functionality there.
• RowFocusChanging - use a row-level CommandButton and put the event handler in ButtonClicking.
• RowFocusChanged - use a row-level CommandButton and put the event handler in ButtonClicked.
• ItemFocusChanged - a void it entirely. If possible, use a control like a CommandButton and put functionality there.
• ItemChanged - avoid it entirely. If possible, use a control like a CommandButton and put functionality there.

This means that you're changing the behavior of your DW to make it more like a Web application.

What's In Store
As a further enhancement to our event handling architecture and response to potential latency issues, we are exploiting ASP.NET AJAX technology in PowerBuilder 11.1. What this would mean for applications is better performance for DataWindow event handling - while events would continue to be processed on the server. The DataWindow would only be re-rendered if the DataWindow were modified.

Conclusion
One of the objectives of PowerBuilder 11.0 is to let you deploy your existing PowerBuilder applications as ASP.NET Web Applications with as little code change as possible. Because the Web is a very different environment from the client/server architecture that your application evolved in, you'll want to continue to evolve it in its new environment. We hope what you find here will help you with that.