Welcome!

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

Related Topics: PowerBuilder

PowerBuilder: Article

HyperText Objects or the PowerBuilder VM Anywhere Part 2

HyperText Objects or the PowerBuilder VM Anywhere Part 2

In Part 1 of this article (PBDJ, Vol. 8, issue 12) we presented the technology for building and using HyperTextObjects (HTOs). HTOs enable authoring of powerful HTML/JavaScript controls that can easily mimic the functionality and APIs of PowerBuilder controls.

Now we will explain how HTO technology enables you to rebuild an entire PB Virtual Machine for the Web. Then, addressing the business purpose - that your Web application code can become a simple line-by-line port of the original PB app - we'll demonstrate an integrated example based on PowerBuilder's Data Explorer demo screen. (In our previous articles, "Converting Your Client/Server Applications to the Internet" [XML-J, Vol. 2, issue 3] and "XMLControl or DataWindow Anywhere" [PBDJ, Vol. 8, issue 3], we covered related topics, such as the integration of the proposed solution with any J2EE server of choice ( as well as with an IIS/.NET server).

PowerBuilder Virtual Machine on the Web
In Part 1 we created two trivial controls: a groupbox and a PB-like checkbox. In a similar way, it's feasible to re-create every PB control for the Web. While authoring complex controls such as the menu, tabfolder, and TreeView can take weeks, once developed, they offer the same productivity, and the same advanced look-and-feel and coding simplicity as their PB counterparts.

It would take a major effort, of course, to rebuild the DataWindow control - the crown jewel of the PowerBuilder environment. While replicating a complete DataWindow in JavaScript would be extremely difficult, we believe that a different approach can lead to even better results.

In our article "XMLControl or DataWindow Anywhere" we mentioned XMLControl, an HTO that uses an XML standard for data presentation and storage. In addition to most DataWindow APIs, it features direct integration with MS Office components for charting and building spreadsheets, pivot tables, and more - all 100% JavaScript. Legacy PB DataWindows can be automatically converted to XMLControl DataSources (J2EE objects) by the DW2Java program and instantly deployed to any J2EE application server.

All in all it means that using Internet Explorer as a virtual operating system powered with an HTO-based PowerBuilder object model results in a reincarnated modern PowerBuilder Virtual Machine for the Web.

Power of JScript or PowerScript Anywhere
One of the inconveniences of generic JavaScript is the way scripting is attached to events via event-handler functions within the element markup. With this technique the "visual design" portion of the HTML page becomes cluttered with references to "code sections": you have to be very careful to name the function the same way inside the element tag and the <SCRIPT> tag. You also need some kind of function name mangling if you have more than one instance of a similar control on the page. For example, if you have checkbox cbx_1 and button cb_1 inside your <BODY>:

<BODY>
<control:checkbox id="cbx_1"
onItemChanged="cbxOneChanged();" />
<input id="cb_1" type="button"
onclick="buttonOneClicked();" />
</BODY>
then inside your <SCRIPT> you have to provide functions with the exact same names:

<SCRIPT>
function cbxOneChanged() { . . . . . }
function buttonOneClicked() { . .
. . . }
</SCRIPT>
On the contrary, JScript (an Internet Explorer flavor of JavaScript) supports the "magic" name-based dynamic binding of elements with event scripts located outside the HTML markup. Rewriting the previous example we could have had the "visual portion" changed to:

<BODY> <control:checkbox id="cbx_1"... />
"input id="cb_1" type="button"/> </BODY>
while the "scripting section" could use any of the following three syntaxes, including one just introduced in PB8 for script binding:

<SCRIPT>
function cbx_1::onItemChanging()
{. . . . . }
function cbx_1.onItemChanged()
{ . . . . . }
function cb_1_onClick()
{ . . . . . }
</SCRIPT>
You can have your JScript code structured and laid out exactly like the PowerScript "export" of controls. Also, please keep in mind that the upcoming .NET version of JScript - JScript.NET - shares a common runtime with C# and VB, providing JScript developers with all the libraries and full power available in C#/VB/.NET. It supports object inheritance and the implementation of interfaces via "extends" and "implements." Code written in JScript.NET can be precompiled into p-code for high performance.

In other words, JScript.NET can become the language of choice for client-side development, surpassing Java or C++. And PB developers, armed with JScript and a PB Object Model disguised as HTOs, get cross-platform support for new and existing applications.

Welcome to PowerScript anywhere!

TreeView Control and Other Framework Objects
Soon after PB5 introduced the "native" TreeView control, PB developers started fitting it into the different "framework" settings. We all tried to automate the population of "trees" with nonvisual services and DataStores. Then the PFC came to the rescue in simple cases, leaving you on your own for anything slightly more dynamic or hierarchical. Let's show how the neatly combined power of XML and JavaScript simplifies the task these days.

We'll start with the construction of a TreeViewItem. At a minimum it should contain a label of the item. Optionally it may have a URL to download the item picture and a URL to get the children items:

var tvi = new TreeViewItem("XMLSP
Examples",
"Objects.gif","examplesTV.xml");
Preserving the PowerBuilder way of thinking, it would be logical then to expect the following "population" code in the window::onload event:

function window::onload() {
// Populate the root item
tv_1.insertItemLast( null, tvi );
tv_1.expandAll( tvi.handle );
tv_1.selectItem( tvi );
}
Accordingly, when it's time to populate the item (the corresponding implementation of TreeView HTO would have to do onItemPopulate.fire(), passing us the clicked item entirely) we should get the code in Listing 1. (This code results in the TreeView shown in Figure 1.)

At any rate, the actual attachment of a new item to a tree happens within insertItemLast() of TreeView.htc:

function insertItemLast(parentItem,
newItem) {
maxHandle++;
if (parentItem==null) pElement =
document.body;
else pElement = document.all
(""+parentItem.handle);;
. . . . . . . .
var s = '<DIV style="height:18px;...">+
'<SPAN title="' + newItem.label + '">'+
'<img src="'+newItem.pictureName+'/>' +
newItem.label + "</SPAN></DIV>";
pElement.insertAdjacentHTML("Before
End",s);...
return newItem;
}
Please note that instead of TreeViewItem we could have passed any object to insertItemLast() as long as it has "label" and "pictureName" properties - there's no type checking on JavaScript arguments. By the same token it also means that we can add almost any object to the tree. Depending on the level or the current node, choose the properties that you need and access them directly by name. All our PowerBuilder NVOs and additional data types in extension layers are no longer needed.

Also, please note that the population of the node from a server-side URL makes it a truly distributed solution.

Integrated Sample
Finally, let's make a "real application" and integrate a couple of databound controls. As a basis we'll take a "TreeView/DataWindow Linking" sample from a PB example application. This example features a TreeView with four levels of drilldown links to associated DataWindows. While looking at the "window" in Figure 2, note that this is a pure browser application, not a PB one!

We created this "window" by porting the original PowerBuilder's sample, "w_tv_dw_lnk". To start the port we migrated all four DataWindows and the related dropdown ones to XMLControl DataSources using the DW2Java converter (available at www.xmlsp.com/DW2Java). Then we exported "w_tv_dw_lnk" into an ASCII file named dataExplorer.htm, using the library painter. Finally, we went line by line through the dataExplorer.htm and replaced PowerScript statements that refer to PB components with JavaScript statements that refer to HTOs. The code presented in Listing 2 reflects the resulting dataExplorer.htm. In fact, it's three times smaller than the original PB source. What paid off was the XML-based data model in XMLControl plus the extensibility of JavaScript objects, which enabled the reuse of a native data model in both the TreeView and XMLControl.

Beyond PowerBuilder
With the proliferation of Web publishing, the creation of the J2EE platform and application servers marked a tremendous technological advance overall; however, the IT industry has been deprived of Web application tools that can compare to the productivity of RAD tools like PB or VB. The main reason is that RAD tools of the client/server era assumed authoring of rich GUI components, whether PowerScript UserObjects or binary components residing in DLLs. Both PB and VB took advantage of standard Microsoft Windows technologies, which enabled the development of such components in an object-oriented fashion.

Many Internet developers expected Java to become the "object model provider" to enable component development regardless of the browser. It's obvious today that Java Swing did not deliver. This lack of an effective and universal mechanism to create rich GUI components for browsers even contributed to the popular illusion that solutions based on the rich GUI logic are not J2EE compliant. This misunderstanding would be similar to the belief that all PowerScript GUI logic should be packaged as database stored procedures or become non-SQL compliant.

The timing of the HTO technology described in this article is not accidental. Similar to PB, which came "on the shoulders" of Microsoft Windows, HTO technology depends on the features introduced in Internet Explorer 5 to become part of the .NET platform foundation. It all but assures the re-creation of PowerBuilder for the Web in the near future. Then, it's up to PB developers to capitalize on the powerful object model, the existing code base, and a profound understanding of IT needs.

Think positive. Think PowerBuilder.

Summary
In this article we briefly described the "evolutionary" approach to the redeployment of PowerBuilder applications on intranets and the Web using the J2EE environment. It's based on the substitution of native PB objects with HyperTextObjects. More information, as well as an on-line implementation of a DW2Java conversion tool, can be found at www.xmlsp.com, a site maintained by the authors.

More Stories By Victor Rasputnis

Dr. Victor Rasputnis is a Managing Principal of Farata Systems. He's responsible for providing architectural design, implementation management and mentoring to companies migrating to XML Internet technologies. He holds a PhD in computer science from the Moscow Institute of Robotics. You can reach him at [email protected]

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.