The first time I started developing PeopleSoft applications was on version 7.x. Back then, my previous client-side RAD coding experience is with VB6. It was amazing back then to be able to develop an application much more rapidly than VB6. When I learned PeopleCode, it is a bit appalling to see how primitive the language is, even though it borrows quite a lot of syntax from VB. This doesn’t matter though, PeopleCode was just an icing on an already delicious cake. The PeopleSoft application framework already delivers a lot of advantages.

When 8.1x came out, I was delighted to see PeopleCode adapt dot-notation object-style syntax for most of its data access — eliminating the need to use those convoluted functions of 7.x that makes PeopleCode coding a pain to use. The mapping of fields, records, rows and rowset to an object heirarchy makes a lot of sense and it made coding and reading PeopleCode a lot easier. Again, there was a shortcoming — you could only use built-in classes.

8.4x introduced Application Classes. This alone made me very excited about coding 8.4 PeopleCode. I know 8.4 has been around for more than a year now. But it has only been recently that our client upgraded to this version. Now I have the opportunity to create real world applications that take advantage of custom classes.

An Application Package is simply a new type of PeopleSoft definition where custom classes are stored. It is quite similar to packages of other object-oriented platforms. Inside an application package are heirarchies of subpackages. A (application) class will reside on one of those subpackages like so:

AppPackage:SubpackageLevel1:SubpackageLevel2:Class1

An application class will have a number of methods and properties. Each member (method or property) can be public or private.

Application classes supports the following:

Polymorphish

This is already exhibited by built-in classes in 8.1x
Inheritance

It even allows inheritance of built-in classes. I’m excited about this as this gives the programmer/designer a lot of room for creativity compared to the previous version of PeopleCode.
Aggregation

Aggregation is a valuable feature. It seems to be the best way for custom classes to manipulate the data buffer directly.
Method Overloading

From what I can tell, it doesn’t support method overloading.
Abstract classes

By simply changing the class declaration to an interface, you get an abstract class. Useful for big projects. I should read this article to understand the advantages.

Interestingly, the PeopleCode editor inside an application class fixes other flaws in PeopleCode too. Dynamic variables are no longer supported, all variables inside methods and properties must be declared. This is something that is to be appreciated. As the code inside classes gets larger, don’t expect bugs to arise because of spelling errors in variable names. On the negative side, functions that work on normal variables don’t work with instance variables. An example of such functions are All() and None(). There’s no reason they shouldn’t work. There’s no reason that instance variables will behave differently from normal variables.

Overall, I hope to have more opportunities to work on application classes. They do allow code to be more streamlined, more reusable, and easier to debug. There are still many aspects of application class building that I still need to explore: exception handling, collections, down-casting, abstract classes…

I don’t have a formal training on using application classes, but the documentation, though short, was able to get me started. I believe it is lacking. Some syntax and concepts are not explained well. It took some re-reading and experimentation to understand some concepts. A better tutorial for beginners is called for. I just hope I have the energy and perseverance to create one.