Welcome!

PowerBuilder Authors: Chris Pollach, Yeshim Deniz, Jayaram Krishnaswamy, Kevin Benedict, Avi Rosenthal

Related Topics: PowerBuilder

PowerBuilder: Article

PowerBuilder Cover Story — The DataWindow in PowerBuilder 11 Web Form Targets

Transforming an existing PowerBuilder application into a Web application

PowerBuilder 11 introduces the WebForms target, which lets you transform an existing PowerBuilder application into a Web application with relative ease. While the deployed application will be remarkably faithful to the original client/server deployment in terms of application behavior, the degree of faithfulness is limited by the fact that your application is running as a Web application. The PowerBuilder component where this poses the greatest challenge is the DataWindow.

The aim of this article is to point out where the transformed application will differ in terms of latency, performance, and look and feel and what you can do to minimize these differences.

"New" Features
Other than the fact that the WebForms DataWindow runs in the browser, another source of differences in behavior with respect to the traditional client/server DataWindow is the fact that the underlying implementation is the Web DataWindow. We have narrowed this gap by implementing:

  • True Dropdown DataWindows
  • The Dropdown Calendar
  • The EditMask
  • The TreeView processing style
  • Browser locale
Pagination
In client/server applications, the number of rows appearing in a DataWindow is dependent on the size of the control. The FirstRowOnPage and LastRowOnPage properties give you the rows that are actually visible on the page. Scrolling or resizing the DataWindow changes what rows are visible but the DataWindow makes sure that rows are displayed in their entirety - either they're fully visible or they're not visible at all. The vertical scrollbar ranges all retrieved rows (see Figure 1).

In a WebForm application DataWindow, a "page" comprises the rows that happen to be on the browser at any given time. It's possible for the page to comprise all retrieved rows, but by default the page size is 20 rows. The page size serves as a way to tweak performance by controlling the amount of data received and rendered by the browser. In Figure 2 the 20 rows can be scrolled, but to view rows outside this batch of 20 the page navigation bar at the bottom of the DataWindow is needed.

In a WebForm it's possible to make some rows only partially visible through scrolling or resizing. (The DataWindow in a WebForm application doesn't support the FirstRowOnPage or LastRowOnPage properties.) This is in contrast to the DataWindow in a client/server application where the page by definition is all rows that are visible. Another difference is that the scrollbar doesn't range all retrieved rows, only the rows in the page.

The default number of rows per page is configurable through the Configuration tab in the project painter (see Figure 3).

However, this setting is application-wide. To set the number of rows per page for a given DataWindow, use the Rows Per Page property accessible through the Web Generation tab of the DataWindow property pages (see Figure 4).

Uses Script Callbacks
Pagination doesn't use postbacks - instead it uses script callbacks. This means that only the navigated DataWindow will have its contents updated - there's no overhead of re-rendering the entire page.

The Dropdown DataWindow
The default implementation of the DDDW in a WebForm application uses the HTML select tag. Not only does this introduce something different from the original client/server application, it also doesn't scale well because the exact same tag is repeated for every row in the DataWindow. Having more that one DDDW in the DataWindow compounds the problem.

An option exists to render a dropdown as a true DDDW instead of using the HTML select tag. The technique used to render the dropdown as a DDDW shares data across rows, making it more scaleable (see Figure 5). Setting PBDataWindowEnableDDDW to true in the Configuration tab in the project painter can turn on this option.

You can further optimize the rendering of your DDDWs by loading it only on-demand. Using this option, the DDDW isn't sent to the browser when the DataWindow is rendered; it's sent only when the dropdown is clicked. The DDDW is then sent to the browser using the Script Callback mechanism provided by ASP.NET. Setting PBDataWindowScriptCallbackDDDW to true in the Configuration tab in the project painter can turn this option on.

Sharing Read-only DataWindow Data Across Sessions
PowerBuilder applications deployed as WebForm applications allow the data of read-only DataWindows to be shared among different sessions. Other than sharing the data of the primary, delete and filter buffers, the data of DropDown DataWindows can also be shared.

Sharing the Data of Primary, Delete, and Filter Buffers
To avoid duplicating the same data of read-only DataWindows, it's possible to configure your application to share the data across sessions. The specification of which DataWindows to share is done with the PBCachedAndSharedDWs property. Set its value to a string of comma-delimited names of DataWindow objects to be shared.

Restrictions on DataWindows Shared Across Sessions
The following restrictions apply to DataWindow Controls that have a DataWindow object listed in the PBCachedAndSharedDWs entry.

  • Only a single invocation of Retrieve (which must be without parameters) is allowed.
  • No filtering, sorting, deletions, and insertions are allowed.
  • No modifications to the data are allowed.
  • No invocation of ShareData or ShareDataOff is allowed.
  • No invocation of Update is allowed.
When this form of sharing is used, the retrieval events aren't fired. This is because the Retrieve function only shares the data in the cache, no actual retrieval occurs.

Sharing the Data of DropDown DataWindows
It's also possible to share the data of DropDown DataWindows across sessions. The specification of which DataWindows to share is done with the PBCachedAndSharedDDDWs property. Set its value to a string of comma-delimited names of DataWindow objects to be shared if they're the underlying DataWindow of a Dropdown DataWindow column.

Restrictions on DataWindowChild Object References to DropDown DataWindows Shared Across Sessions
The following restrictions apply to DataWindowChild object references to Dropdown DataWindow columns that have a DataWindow object listed in the PBCachedAndSharedDDDWs entry.

  • No invocation of Retrieve is allowed.
  • No filtering, sorting, deletions, and insertions are allowed.
  • No modifications to the data are allowed.
  • No invocation of ShareData or ShareDataOff is allowed.
  • No invocation of Update is allowed.

More Stories By Frederick Koh

Frederick Koh is a Staff Engineer at Sybase, Inc., and has been a member of the PowerBuilder and DataWindow.NET development team since 2005. Frederick has over 14 years of IT industry experience.

More Stories By Li, Zhao

Li, Zhao is a senior engineer at Sybase, Inc., and has been a member of the PowerBuilder and DataWindow.NET development team since 2006. Li, Zhao has over 10 years of IT industry experience. Li, Zhao has written articles for various computer science conferences and journals.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.