Defining and Using Constants with PS Application Package

I’ve used Application Packages more and more after reading about them in Jim Marion’s PeopleSoft PeopleTools Tips & Techniques.  And I like using them far more than creating functions in a FUNCLIB_ library.

I’ve got an App Engine program I’m developing, and I’m using an App Package class for error handling.  I’ve a small list of error codes that get sent by the exception handler routine and those codes are used to get a description.  I could use message catalog for the texts of course, but in this case I’m going to be lazy and keep the values in the code.  This is for a batch process that will be scheduled to run nightly; it isn’t customer facing.

To avoid having magic numbers appear in my code I wanted to define a set of constant integer values in the App Package class.  PeopleBooks gets a bit obtuse on this subject though.

So, let’s go thru the exercise of creating them, then how to use them.

In the class definition I create a private constant:

private
Constant &INVALID_EMPLID = 1;

So far, so good.  any methods inside the class can use that value:

Evaluate &errCode
When = &INVALID_EMPLID
&msg = “Invalid emplid provided.”;
Break;

But I want the code throwing the exception access to the same constant.  PS App Package definitions are – well – eccentric.

Java, C++ and C# class structures look similar.  You define the class, then add fields if needed, and the methods of the class.

App Packages have methods, but then bring in the idea of properties and instances as well as Constants.

A property is exactly that, it’s a property of the instantiated object from the class – it’s the Has A of the object.  As in my class House Has A property of RoomColor.  PeopleBooks provides an explanation for a property as an attribute of an object.

Instance variables are like Static variables in Java.  An instance is private to the class, not just to the instantiated object.

Which gets us nowhere in terms of having our constant value used in my exception handling – yet.

Here is the key part – PeopleSoft set up properties to take the place of creating get and set methods.  They consider it more efficient to declare a property (which has no parameters) than to use a method to do get/set routines.

So instead of having a method:

method getSomething() as integer;

You would instead declare a property:

property integer mySomething get;

This was the long way around to explain how I get to use my Constants definition.  You saw above where I created a constant for &INVALID_EMPLID.

I declare a public (this has to be public – PS will bark at you if you try to do anything else with it) property – making sure it has a get as part of the definition:

property integer invalidEmplid get;

Then you write a get routine:

get invalidEmplid
/+ Returns Integer +/
Return &INVALID_EMPLID;
end-get;

Now my App Engine code can access that constant value – assuming that I’ve declared the App Package Class inside the code:

&errnum = &err.invalidEmplid;

If I find later on that I want to change the value &INVALID_EMPLID points to, I only have to do it in one place.  Less code maintenance, which is the real value of not using magic number coding.

Advertisements

About Lee Greffin
Just another programmer...

9 Responses to Defining and Using Constants with PS Application Package

  1. Pradeep says:

    Hi Lee,

    I have a question. Since it’s not fully related to your post but i thought i would be good place to share my question. In Java we know that the Object class is the parent class of all classes similarly in PeopleCode App Class, who is the parent class? I am curious to know it because i read some where that “A class that does not extend some other class does not need any constructor.” and i am not sure how it can be true.if we will create a simple class Test where it has one class level variable and one method then i will create an instance of this class in order to call that method. If the constructor of this class Test will not be invoked then how class level variable will be initialised? Please give some light on this.

    • Lee Greffin says:

      Hi Pradeep,

      You’ve probably read how Oracle has been less than a perfectly transparent steward of Java? Well….

      I did a quick search and came up with zip. I don’t have any resources within Oracle, let alone the PeopleSoft devs so I don’t have a definitive answer. But I can offer an educated guess based on the documentation.

      PeopleBooks advises that: Every application class is a definition of a new data type in PeopleCode, like the record, rowset, or field data types.

      Okay, so a look at the Object Data Types gives us: Object data types instantiate objects from PeopleTools classes.

      Dig a little further and we find that PeopleTools defines conventional data types as follows:

        Any
        Boolean
        Date
        DateTime
        Float
        Integer
        Number
        Object
        String
        Time

      Then it further defines the object data types.

      Okay – trying to make sense of the above I’d say that PTools uses the same model as other recent object based/oriented languages; you have primitives such as integers, strings etc. That list includes the Object data type – so like Java I’d like to think I’m safe in thinking that would be the base class that the Object Data Types build from. Or I could be entirely wrong; the documentation is sparse.

      Constructors in App Package don’t have to be declared – same as Java. If the constructor isn’t added to a class definition in Java the compiler creates one in the compiled class object (so they say…); it’s deemed as implied. PTools App Package uses the same lazy/efficient idea; if it’s not declared implicitly it’s implied and when complied treated as if it exists.

      In reality a constructor is only useful if you need to plug data into instance variables (for PTools App Package) / fields (Java and C#). And while I’ve seen constructors that were built with parameters I’ve had instructors take a dim view of that usage – your mileage may differ.

      In any case either the explicit or the implied constructor of a class is called each time an object is instantiated using the Create keyword. Interestingly the documentation says that …before a constructor runs, the instance variables for the class are set by default based on their declared types…; this makes sense when you consider instance variables are static and belong to the class.

      Good discussion! Thanks.

  2. Jeff Johnson says:

    Thank you for sharing this information. For other users, you can use the following macro to build your code. Just create an Excel macro with this code, and have in the first tab of the spreadsheet values like:

    Constant1 number 1
    Constant2 number 2
    Constant3 string “Three”

    When you run the macro, it will build your properties section, your private constants section and all of your get routines. Please note that you must add the ref­er­ence “Microsoft Forms 2.0 Object Library” for the clipboard piece to work.

    It should save you a bunch of time. It has for me.

    Sub BuildClass()

    ‘ BuildClass Macro
    ‘ Builds a class of constants.
    ‘ Author: Jeff Johnson


    i = 1
    PrivList = “private ” & vbCrLf

    Do While Worksheets(1).Cells(i, 1) “”
    VarName = Worksheets(1).Cells(i, 1).Text
    Variabl = Worksheets(1).Cells(i, 2).Text
    VarValu = Worksheets(1).Cells(i, 3).Text

    PropList = PropList & “property ” & Variabl & ” ” & VarName & ” get;” & vbCrLf
    PrivList = PrivList & ” constant &” & VarName & ” = ” & VarValu & “;” & vbCrLf
    MethList = MethList & “get ” & VarName & vbCrLf & ” Return &” & VarName & “;” & vbCrLf & “end-get;” & vbCrLf & vbCrLf
    i = i + 1

    Loop

    Set MyData = New MSForms.DataObject

    MyData.SetText PropList & vbCrLf & PrivList & vbCrLf & MethList
    MyData.PutInClipboard

    End Sub

    • Lee Greffin says:

      Hi Jeff, thanks for your comment. I approved it but with some reservations that I thought I’d share.

      Your macro doesn’t declare variables – which means they are all variants. Not a huge deal in this day and age but would have been an issue in production code back in the day.

      It also doesn’t explicitly say that the string created by the macro is written to the clipboard – and the user would have to take the next step of pasting it into the PSoft IDE. Having said that it’s implied by the reference as well as the call to the PutInClipboard method so it is a self-documenting step.

      I also think it’s the basis of a great blog post of it’s own.

  3. Jim Marion says:

    Oh… one more thing… the property get/set concept seems really similar to the VBA object oriented programming style that was almost popular when App Classes appeared in PeopleCode. As you know from my book I prefer the getXXX alternative.

    • Lee Greffin says:

      Wow – back to the hoary days of VB 4 – the initial foray into providing classes to Visual Basic…

      Which in turn was borrowed from getter/setter thinking (in my opinion anyway) in C++. And MS kept that class wizard around until .NET.

      Thanks for the comments!

  4. Jim Marion says:

    Instead of comparing App Class instance members to Java static members, I suggest comparing them to Java instance members (fields). They really are the same thing. They belong to the instance, not the class.

    Great job using App Classes for strong typing values. I really wish PeopleCode had statics. It is quite annoying to have to create a new instance when you want a strongly typed Enum.

  5. Thanks for another enjoyable article Lee.

    One comment though – instance variables are not static variables (in terms of scoping rules, one the same private instance variable is not shared by multiple instances of the class); they are in fact instantiated for each instance/object of the class.

    So if I have a class definition ClassDef, with 1 private instance variable &InstanceVar, and I instantiate 2 objects of type ClassDef, I will have 2 instances of &InstanceVar in memory, not just 1.

    This contrasts with static member variables in Java, where the variable is shared and in the example above, only 1 instance of &InstanceVar would have been allocated in memory.

    • Lee Greffin says:

      Thanks for the comment. I wrote it thinking it was at best an okay analogy; it’s clearly not. I’ll have to edit that out as it is bad information to pass on.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: