Category Archives: Introduction to Powerbuilder
In continuation of my recent post about PowerBuilder – what tier, I would like to explore a little more on the technical front. In any books or articles on the power of PowerBuilder, you will always confront a Datawindow. A Datawindow is the heart of the GUI development in PowerBuilder.
By design, a datawindow is truly 2-tier. You design a Datawindow by adding a SQL Statement – from the database tier, the 2nd tier. Then you design the GUI of the database to be displayed in the client – tier 1. This is a datawindow. If you follow MVC pattern, Model is there, View is there and the controller is sort of built into the GUI itself (like validation etc). It’s a great innovation of that time.
Fig 1. How a (2-tier) Datawindow works – couresy: Hyderabad College
To use a datawindow in such an environment, all you need to do is the following:
dw_employee.DataObject = d_employee dw_employee.SetTransObject(SQLCA) dw_employee.Retrieve()
You are done! (I left out details of the datawindow object, connection parameters and Retrieveal parameters for simplicity). In this case, you are directly connecting to the database from the client and the data flows directly into the datawindow control. You could actually share the data on a datawindow with another (using ShareData function). This allows you to retrieve once and show the same data in different formats.
Then came the n-tier or the distributed architecture revolution. With Datawindow being at the heart of PowerBuilder design, how would you get the middle tier in? Particularly, when the middle tier being the one that’s supposed to connect to the Database.
Before going full on to middle tier in the form of an Application Server, PowerBuilder floated the idea of the Distributed PB as early as ver 5.0. They introduced the concept of HTML datawindows. They also introduced the idea of a Datastore, a non-GUI datawindow object. (Before datastore, we used to create a hidden datawindow, which still painted the datawindow behind the scene and thus still the overhead). These were steps in the right direction to distribute an application. (I have a gripe though that Datawindow (control) and Datastore don’t share the same object hierarchy!! So, you constantly have to test for the type of the object. How Sybase missed such a basic thing, beats me!).
Then came the Application Server called, EAServer. To be able to retain the datawindow and still be able to follow a MVC pattern, Sybase introduced the distributed Datawindow. Well, it wasn’t exactly an attribute of the data model, but a method in the datawindow object to synchronize a Datawindow (or datastore) object structure and data across the tiers. To do this, they use Serializing/De-serializing a datawindow using couple of new methods – GetFullState and SetFullState. See here for more detail.
ig 2. 3-tier architecture – courtesy: Simcrest
With the distributed Datawindow, you create a Datastore in the Application Server (EAServer) and synchronize it with a client side Datawindow (control) with the same structure.
With the Datawindow control being on the client and that you cannot connect to the database directly, above example requires some code adjustment:
dw_employee.DataObject = d_employee // Get the blob from the Server Connection.CreateInstance(iuo_employee) lblb_dwblob =iuo_employee.RetrieveData() dw_employee.SetFullState(lblb_dwblob) ...
Where iuo_employee is a non-visual object created on the server.
Function iuo_employee.RetrieveData() ... ds_employee.DataObject = d_employee ds_employee.SetTransObject(SQLCA) ds_employee.Retrieve() lblb_dsblob = ds.employee.GetFullState() // Somehow send it to the client.
Fig 3. Simple implementation of a distributed Datawindow
There you have it. PowerBuilder somehow, did manage to distribute their GUI object called the datawindow. You essentially create a non-visual Datastore that has the same attribute as the Datawindow control. Retrieve it and send the results as a blob to the client to be shared and shown on the Datawindow control.
Only one problem is that you are sharing both the data and the structure of the Datawindow object between client and server. This is slightly in cotrast with how other platforms would implement this. In Java, for example, your JTable still stays on the client, while the TableModel could be made to use a middle tier object to fetch the data. The middle tier object could then connect to the database to get the actual data.
I would have preferred if they made the Datastore the data/model portion of the Datawindow, instead of making it a new object as a Datawindow minus GUI. This way we could have reused the ShareData function in a distributed capacity in some way and implement the dealings with blob behind the scene. But that’s crying over a spilled milk. EAServer and the associated architecture is going away and thus the idea of distributed datawindow may disappear from PowerBuilder altogether. (However, Appeon may carry the concept forward. See here).
Work has been busy for a while. I am finally returning to my blog on PB.
We started looking at PB program as a collection of Objects in the last post. Yes, PB is now an object oriented language, but it sure did not start that way. Sure it has some objects like windows, buttons etc, but does that make it an Object oriented environment automatically? This topic itself is so huge, So, I decided to touch on these first before continuing further with PB.
What is an Object?
The simplest definition of an object is a thing, a noun or an entity. In the programming world, this has come to mean a self contained programming unit. By hooking different “objects” you can make a program. Objects themselves are not new. Remember the old C programs? When you compile individual C files in a program, they were converted to “object” file. Though it doesn’t mean the same, it stands for a program unit. By linking different “object” files, we arrived at the final program (Executable). Then there were modules. Even though there is a subtle difference between a module and an object, in theory they are the building blocks of a program. Remember, COM (Microsoft .Net evolved out of this eventually)? The idea was to have bunch of OLE (eventually called Active-X) that would be glued together in a program. In fact, Visual Basic was invented for such a purpose originally. We will explore more about objects in the coming posts. But, while you are at it, think about another term frequently used in OO: a Class. Several authors allude this to a blueprint, cookie cutter, a mold for creating objects.
What is Object Orientation (OO)?
An object has several other characteristics that makes an object in an Object-oriented language different from earlier definitions of objects. If you Google for the word “Object oriented”, you will find a million links. If you sift through all those, you will come to the following conclusion:
Object Oriented is a new paradigm (though it’s been around for 30+ years now) and it is difficult to learn and/or master. Yet you see, every programming language (PHP, Coldfusion, PERL, PYTHON, you name it) out there is joining the OO way. So, if you are going this route, you have to get the concepts right.
Object oriented is many different things to many different people. Even the languages that claim to support OO now, are not fully OO themselves. So, let us discuss fundamental definition of being object oriented. In later posts, we will continue to drill down this topic.
Several books talk about Object Oriented (OO) approach to contain the following four basic characteristics
We will analyze each of these below.
Almost anything we do with computer software is an abstraction of the real world. An ATM machine is essentially modeled after a real-life teller it came to replace. Abstraction itself is not OO. Cobol and Fortran programs abstracted business models and mathematical models respectively for about 50 years now. But the abstraction in OO, is much closer to the real life. After all, real life is full of objects: people, earth, machines, food, microwaves, books, TV, radio etc.
In OO, we try to call a Radio a radio and define it’s properties and operations to emulate real life one (actually a radioObject is more appropriate name for it; of course, it’s a software object not a real one, but you could make it to play music!). A software abstraction is context based. For e.g., when we abstract customers, shop owners and employers we are abstracting people. In such an abstraction, we definitely would like to know their names, but we don’t need know their race, gender, height, weight etc. Where as, if the person abstracted is a patient, suddenly some of these characteristics matter!
A speedometer in a car is a good example for abstraction. We see the needle to get an idea as to how “fast” or slow the car is going. Abstraction in this case varies between MPH in the US to Kilometers in some other countries. A thermometer, similarly abstracts how “hot” outside temperature is.
This is the next characteristic of an OO programming environment. Encapsulation, simply means hiding private data and showing proper (public) interface. We don’t want to see inner-workings of a microwave or a car when we are using it to heat our pizza or driving to get one. When we shop for a car, we are happy if we find a steering wheel, something that looks like gear, brakes and of course, those 4 wheels that the car needs to “run”. Of course, some of us would like little more glossy finish, but none of these involve putting engines right next to you on the front seat! And of course, the way those engines come pretty well sealed these days, they are very well encapsulated themselves. There is one “interface” you see, the oil cap that lets you fill oil. The content, level of oil, is not immediately visible. If you open and use a dip stick, you can find out the actual level of oil!
Speedometer mentioned above is also a good example of encapsulation. To “see” speed one doesn’t need to look at rotating gears, tires, road etc. They just look at the interface called “Speedometer”.
Encapsulation itself is not a new concept. It’s been around since the early days of programming. In Pascal, you could achieve certain amount of encapsulation by proper function design. C of course, offered modular programming (file level – see post “Modular progamming in C” for more information).
The most common meaning for this English word is the property (read “Wealth”) inherited from ancestors when they pass on. And it’s not just property that can be inherited. We also talk about some characteristics passed on (genetically). It’s this latter mean that’s adapted in the computer lingo. Inheritance in OO allows an object to acquire properties and behavior of some other. So, we talk of a Dog object inheriting properties of an animal object (actually class, we will discuss these shortly).
Of course, in real life we don’t say Dog inherited from Animal. We say, Dog “Is A” animal. We also say Car “has a” engine. And we have access (reference) to computers in the hotel. These are different types of object relationships in OO. An “Is A” is considered to be inheritance. A “Has A” relationship is called composition. And a reference to an object out there, is an Association.
Of these, Composition and Association were possible is non-OO languages as well. Inheritance itself could be indirectly implemented through these 2. For e.g., in C, using plain structures and function pointers we could mimic any of the above relationships.
This came from a Greek word. Poly means many, morph – form. For e.g., different forms of shapes. Circle, Square, Rectangle and Triangle are all shapes. Of these, Rectangle and Square are similar, in that they both have sides. Circles and Ovals could be similar.
Now, shape is a noun, an object. How about a verb – an action or behavior? Let’s take the word “Play”. Try using this English word in sentences and you will see how many different objects can play in how many different ways. Like playing a piano, like playing Football, Playing cards, playing a part in a play, Play with a child, Playing with life! This is truly a polymorphic word. How about the word, “Talk”? “Talk” to a dog, barks, cat meows and the cow moos, not exactly talk in the human sense, but in the sense of “open your mouth and make a sound” it’s the same operation, with various forms!
In this post, we tried to explain what OO is and try to understand the terminologies typically related to the OO. This wasn’t totally a technical discussion. Now that we got some definitions out of the way, let’s get down to business with the topic of Object Oriented. Try to remember some of the examples when we get to our next post.
Below picture summarizes all these terminology as they relate to a Microwave.
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.
PB IDE, just like any other windows application is an MDI application. It is made up of several windows and menus and toolbars. When you open the IDE, it opens up with no Workspace. You need to create/open a Workspace (using options in File menu) to work on a specific project. A Workspace wraps around one or more Targets which in turn includes one or more Libraries. The libraries contain the objects. The objects themselves have properties and methods like in any Object oriented environment. The objects also contain events as Powerbuilder is an event driven programming environment.
Navigation through the project hierarchy is available through a tool called System Tree. The IDE also contains a full menu toolbar called Powerbar that lets you perform several tasks including creating various components in the project hierarchy. The IDE is made up of several individual tools and wizards, which are called Painters. There is a painter for each type of object and each task in PB.
System Tree & Powerbar
The System Tree is a project explorer. This let’s you see the project hierarchy mentioned above, in a tree like fashion. The TreeView object fits this hierarchical structure perfectly. The topmost parent in the tree is the Project Workspace. You can drill down targets and libraries to object properties and methods here. You can expand or collapse at any level in the tree. You can open any existing objects in the System Tree (by double-clicking on them).
Powerbar is the Powerbuilder menu Toolbar containing buttons for important menu items. You can create new objects by Clicking on the “New” button in Powerbar (or File->New option in the menu).
Clicking on New opens up a pop-up window that has several options (buttons) to open various wizards and tools in PB. You can create workspace, target, PB objects including windows, menus, datawindows from here. You can also open up several tools and wizards, such as Library explorer, Database wizard, File Editor, PB Profiler etc, by creating “New” instances of these. Every such wizard or tool in PB is called a Painter.
Fig 1 – Powerbuilder System Tree & Powerbar
Fig 2- New Option in Powerbar leads to “New” options Pop-up
As mentioned above Powerbuilder IDE is essentially made of several Painters. Each specific component type has it’s own Painter (Object Editor) and several tasks have associated Painters (Tools or Wizards). So you will see Window Painter, Datawindow Painter, Database Painter, Library Painter etc. Each Painter is self-contained unit and has it’s own menu (and toolbar), a control(s) list and properties sheet. As you can see, Powerbuilder IDE itself is designed in an object oriented way.
You open the individual component painters when you open an object in System Tree View or when Click on New on he menu bar. Several task and tool painters can be opened in Powerbar.
Here are some of the Painters are available in PB:
- Application Painter
- Window Painter
- Menu Painter
- DataWindow Painter
- Function Painter
- User Object Painter
- Database Painter
- Library Painter
- Project Painter (this is used to build applications – sort of compiler/linker options window; more about this later).
PB IDE – Other parts
Apart from these, the IDE UI has the following components:
An Output (child) Window which shows all the messages from the PB IDE environment, such as compiler outout, error messages etc.
A To-Do List Popup – Here you can enter a “todo” list. You can enter your own laundry list of things to be done in a project. Some of the wizards in PB also create To-Do entries automatically.
PB IDE includes a Browser window, which lists out all the objects in the project. This tool is very useful in locating objects in a large project with lot of libraries. As of version 10.5, it does not have a search capability yet, but you can navigate through libraries and types of objects to easily locate an object. Once found, you can “Edit” the object.
There are also several tools and wizards available in PB. Application Profiler, Debug Window, Database Painter, EA Server Profile etc. Each of these have special Toolbars attached to them.
See below link for more information (The link is for PB 11.0, but still applicable to any version > 8.x in general).
the last few posts, we talked about PB a lot. My last post on Hello World gave an introduction to PB as a programming language. Now, it’s about time we introduce Powerbuilder, the programming environment itself and how to use it to successfully develop a simple application.
PB as a n-tier tool
PB started as a simple client/server tool. We and PB are now in n-tier world. This means an application could be divided into multi-tiers, such as a client and one or more application servers connecting to the database in the backend. Even the client can be multiple, as in you may have a PB application client in the office, a web page accessing the same servers etc. Dividing the application logic into logical blocks of client and server(s) is called application partitioning. Java J2EE is a great multi-tier development environment in 3GL. PB has grown into a n-tier tool in the 4GL world. Sybase has come up with an Application Server called EA Server (originally called Jaguar in version 7). You can now use it to build not only windows applications, but middle tier applications (Application Servers) and Web Applications as well. To handle this new world, PB has completely changed it’s own GUI as of version 7.
When you open PB (versions > 8.x), the first thing you will see is the workspace. A workspace comprises of several “Targets” each target representing a piece (partition) of the application that can be independently deployed. A target can be for different type of applications – a windows client application, a Jaguar component, a DLL, a JSP program, a .Net program etc.
To the target, you add the PB libraries, by adding it to the library list. A library list is not only for housekeeping of libraries in a target, but at run-time this serves as the search path for the application to find objects.
And to the libraries, you add objects such as Applications, windows, datawindows etc. When you create a windows client application, an application object will be automatically added to the library just created. Below images show the various parts of a workspace. We will start looking into each of these in detail in the coming posts.
In my earlier post, I wrote a very simple program in Powerbuilder (PB) to print/show Hello World. I tried to compare with many other programming languages there. In that post, there were several concepts introduced. But, being a simple post, I ignored most of the details. We will try to analyze the details here and this way explain what it means to program in PB.
Interpreted or Compiled
From that list of examples I had, there is one thing that stands out. PB looks a lot more like C/C++/Java, at least in commenting style. But, then we see it has the simplicity of Basic program that it’s usually thought of as originating from. It also has a lot of similarities with Visual Basic (For that matter with other flavors of BASIC such Power basic as well). PB is actually the tool and it uses proprietary language called PowerScript. Like BASIC this is an interpreted language, but not interactive (In a BASIC interpreter, results were displayed as soon as you type a command (or a command block) and press ENTER.). In PB, though the code is interpreted, it’s not the original code that you typed in, but an intermediate code it generated when you compiled (generated) or ran. More on this below.
PB is at the very least, an Object based language. Windows environment contains windows with several controls or widgets on each window. The various controls and windows (objects) talk to each other through events and methods (functions). Now, this itself doesn’t make it object oriented, but definitely object based. In PB (as in VB) an application is made up of several objects such as Application, Windows, Buttons, Text Boxes (and Data windows – more on this later). You cannot have a program without an application and you cannot communicate with the users without windows or buttons. So essentially when we build a PB application, we are reusing these “objects” as templates to make our own objects. Thus, by the very nature PB is Object based.
Real Object orientation came to it in later versions. A rudimentary “user object ” was introduced as early as ver 3.0 and by Ver 5.0 Pb introduced Object-oriented concepts such as function overloading. Many of us still write object based code in PB, but there have been some movements to make it more and more object oriented. There were several frameworks developed for PBincluding PFC, which is still strong in the Client/Server world. A more sophisticated EAF was developed for PB in an enterprise n-tier world. A lot more companies seem to be dusting off their old PB programs and try to upgrade latest versions of PB. So, as a developer you will see both object-based and object-oriented code out there. This is different from Java perspective which is Object Oriented to the core, but not unlike C++ where people continue(d) to code C style programs.
User Interface (IDE)
When we did the hello world, we mentioned what we coded and what we saw. But, we did not mention how or where we coded it. A Java program can be coded in a simple text editor like Notepad or more sophisticated Eclipse or Netbeans. It can then compiled and executed in a DOS (or unix/linux) command line. Or like in Eclipse, all these functionality can be done in one tool. Such tools are called IDE – Integrated Development Environment. PB has been IDE from the beginning. In fact, you cannot code or compile PB outside Powerbuilder (not exactly true, particularly the compiling part). Unlike other tools, PB is a more complete IDE and allows you, as a developer, to debug and run from within itself. Also, the code that you put into PB is actually stored in files with the extension .pbl in proprietary format. More on these later.
Types of Applications built in PB
What is not revealed in the Hello World program is what kind of programs can be written in PB. Apart from the windows programs, PB can also be a great Client/Server tool. In fact, in corporate environments it is mostly used as a Database programming tool. It’s strength lies wholly on the simplicity of database connectivity with the use of Datawindows. With the advent of EA Server, PB can be a great n-tier development tool as well, like Java J2EE. (More on these later).
As mentioned above, PB runs in an interpreted mode. When you compile a PB program, it gets compiled into p-code, a proprietary bytecode. In this regard PB is very much like Java. Just like Java, there are options to compile into native machine code, but typically p-code is preferred. Thus, to run a PB application, you need to install a PB runtime. This is very much like a Java VM. (In fact in EA Server terminology, this is called PB VM). So, theoretically, PB application can be ported and run anywhere PB runtime was available. There were Unix versions of PB available. But, you need a specific version of PB runtime to run a program generated with a specific version of PB. Here it is different from Java, where future runtimes are guaranteed to be backward compatible and thus can run older versions of Java classes.This makes PB less portable. Also, by the windowing nature of it, it naturally fits into Microsoft Windows. The direction Sybase is taking, seems to confirms this. PB12 is, apart from being a windows application builder, also an IDE for .Net plaform.
Starting from my next post, I will go into more details about using the product.
Powerbuilder grew from the modest beginnings in the early 80’s to where it is now. Those of us who have worked with it for a long time know that it’s come a long way as a product. But how many of know it’s real history (sort of like the history PC programming world itself)? It was originally conceived and produced by a company called Powersoft. Now it is owned by Sybase. We all knew that it was “bought out” by Sybase in the 90’s and what it did to the product. But how many of us know the background of it? Both Powersoft, the company, and Powerbuilder, the product had their fair share of competitions from big giants, threat of hostile takeovers. After initial days of glory, it did lie in the dumps for some time and several wrote death sentence for it. Yet, time and again it came back up again and with PB 12 seems to have gained a new life. I can write about all those here. But, I won’t try to re-invent the wheel as there have been several nice posts about the subject. I am listing a few, that I liked, here: