PB 101 - Contd... Project Workspace

As mentioned earlier, PB is geared up for developing applications for various platforms. We saw how the IDE is built around the Project Workspace, and the tools it provides to access every in the workspace. First let's define the various parts of a Powerbuilder based software development project.



Workspace

This is the fundamental entity in PB based development project. This is sort of a container for all targets, libraries and objects in a Powerbuilder project. This is not very different from Visual Basic Project or Eclipse Workspace. To the workspace, you will add targets, which are self contained applications. Thus, you could just have 1 workspace called "MyPBWorkspace",  where you can dump any number of distinct applications, be them related or not. A more logical design for a workspace is to create a workspace for each application project you work on. For e.g., HelloWorldWS could encompass all that is related to Hello World App. A BankingAppWS could include client, server, web pages related to a Banking Application you develop. The information about the workspace are stored in the file system as a text file with .PBW extension. Here is what a Workspace file contains for the sample HelloWorld application:

Save Format v3.0(19990112)
@begin Unchecked
@end;
@begin Targets
 0 "myfirstappTarg.pbt";
@end;
DefaultTarget "myfirstappTarg.pbt";
DefaultRemoteTarget "myfirstappTarg.pbt";

The actual contents of the file could vary by version and the number of targets we have. But the important settings are, where it lists the targets in the workspace and the DefaultTarget (where the application object is).

Target

A Target is nothing but an Application. But, since we are used to the term Application (at least in Windows context) to refer to the GUI client/server applications, Sybase had to come up with the term Target to refer to all types of "Applications". Apart from the traditional client application, you can now develop a target for EA Server, Web target etc. A target wraps around all the objects in an application, but since objects in PB are stored in libraries, a target is just a list of all the libraries that make up an Application. Each target is stored in a file with extension .PBT. For our sample application, here is the contents of the target file:

Save Format v3.0(19990112)
appname "myfirstapp";
applib "myfirstappLib.pbl";
liblist "myfirstappLib.pbl";
type "pb";

As you can see, the target file has settings describing the application name, the library that contains it (applib) and the list of libraries that make up the application. Notice the type "pb". This is because our first application is completely in PB. There are other types. For e.g., for JSP target, it is "jspweb".

Library

A PB Library is a unit of repository for source code and objects in a Powerbuilder Application. When you open a library (in Library Painter*), you will see all the object that make up the application. One or more libraries can be added to an Application (Target) . A library is stored in a binary file with extension .PBL. Where as, Workspaces and Targets were addded in PB 8.0 onwards, PBL has been the fundamental building block of PB Application from day 1. Earlier versions of windows had restrictions on the size of a PBL file and this was often the cause of GPFs in windows applications. Currently there is no such restrictions, but it's still advisable to keep it to manageable sizes. The PBL not only contains the source code and all the information about GUI, but it also has temporary interpreted code, so you can run the application from within development environment.

While deploying, all objects in a PBL file could be bundled into an Application EXE or the application could be divided into logical blocks of dynamic libraries with the extension PBD.(This is fashioned after windows own dynamic libraries called DLLs).

Since the PBL file is a binary file, you will have to have Powerbuilder installed to be able to view/edit objects and sources. Powerbuilder also allows you to export individual objects to text files. There are also some 3rd party tools available though you can only see the text format of the objects. Lot of these tools use PB's own export facilities or PB ORCA API to get the sources out of PBL files. More on these later.

When inside Powerbuilder, you can see the objects inside a library (PBL) either in the System Tree or Library Painter. See Fig 1 for a look at the parts of a library in System Tree. You can view or edit these objects by double clicking on them as well. Each object type has an associated editor or "Painter" as they are better known in PB world.

[caption id="attachment_131" align="alignnone" width="478" caption="Exploring PB Library (PBL) in System Tree"][/caption]

Fig 1 - Exploring PBL

Objects

Remember PB was developed under Microsoft Windows originally? It used Windows API in building various components, and almost all components in PB can be mapped back to Microsoft Windows control. PB essentially maps Windows messages to events in PB, so developer can code for it. As PB matured into a Object oriented environment, you saw these controls turning into full fledged objects themselves which you can inherit from. Major shift to this paradigm is the datawindow, which was developed as a self-contained object from the beginning. User Objects is another area where PB pushed it's Objected oriented features further. There are several pre-defined controls or objects in PB. User can also inherit from these or develop their own (User) Objects. Below are some of the types of Objects available in PB:

Application - This is the entry point to the application, sort of like the main in C, main Class in Java.

Window - Unit of display in a GUI environment. A container for all controls; Inherited from Microsoft windows Operating System, where PB was originally developed. See What is a Window? for details on Microsoft's definition of a window.

Menu - If you are a user of any GUI environment, you will know this object. It's a group of options available in an application. Selecting (Clicking on) a menu option executes a specific command or task in the application. Again PB's menu naturally is fashioned after Windows menu system.

Datawindows - Apart from these the most important of all is the Datawindow Object/control. This is self contained object which has several interesting widgets built into it. PB actually takes care of drawing a datawindow itself. Apart from the visual part of the Datawindow, it is objects that can be tied to a specific Database at runtime and has a built in SQL to fetch data. So, in a way it's like DAO or ADO objects in Visual Basic, but only more powerful. Everything inside a Datawindow can be modified at run time, making it the most flexible and most powerful tool in PB. A Datawindow is such a big topic in itself, we will defer it to a later discussion.

User Object - To complete this discussion on Objects in PB, we will discuss User Objects here. A User object is an ancestor object in PB that lets you create custom classes in PB. These classes can be Visual - you can build everything you build in a Window control in a User Object and then use it in a Window control. Since user objects are flexible and can be created on the fly at run time, you can use them to customize displays at runtime easily.

Non-Visual User Object (NVOs as they are better known) is an User Object that does not have any visual components in it. This is similar to the Java Object class. These are typically used as workhorses behind the scene. Since they are not visual, they don't need to be tied to the client Application. This made them perfect candidates for objects deployed to EA Server. We will look in to these in a later post.

Widget Objects

There are other objects called widgets or controls that go inside container objects such as Windows, User Object etc.

Button - Typically refers to the Command Button in Windows. It is a widget that executes certain action when the user clicks on it.

There are several controls/objects in PB to let the user choose options:

Checkbox - for selecting single/multiple options

Radio Buttons - for selecting one of many choices

ListBox, Dropdownlistbox - Lists where user can choose one or more options.

Single Line Edit, Multi Line Edit, Rich Text Edit - Text boxes for data entry in PB

Explanation about PB Objects and Controls


An Object in PB is like a Class in Java. It's the template for an object. When you design a Window in GUI (Windows Painter) you are inheriting from Window class. Let's say you create a window called, w_login. Now, w_login is inherited from Window class.This is like creating a new class in Java by extending an ancestor. The only difference is that in Java, at runtime, you will have to instantiate the class into an object to be able to use it. Where as, in PB the developer doesn't need to instantiate it as a separate object. PB does it for you. So, w_login window is the name of the class and the name of the object at runtime!!

A widget placed on a screen (Window) is called a control in PB. A button object becomes a Button Control once it's placed on a window. So control is sort of like an instance variable of a visual component class. As soon as Button is placed on a Window, it has all the functionalities of a Button Object.

A Datawindow is handled slightly differently. A container called Datawindow Control is placed on a Window. It immediately inherits all the events relevant for a Datawindow Control in PB. But by itself, this control is not useful, as it needs to be tied to a Datawindow Object. A Dataindow object is something the developer designs in the Datawindow Painter. (in OO parlance, it's a custom class inherited from Datawindow Ancestor Class in PB).  In this respect, the Datawindow Control is like an instance variable that's a pointer to a Datawindow Object.

The DataWindow Object pointed to by (tied to) a Datawindow Control can be changed at run time. The object itself can be modified by using any number of functions and thus the flexibility of the widget.

Fig2 - Class relationship between various PB controls