|Component PeopleCode||KEVIN RESCHENBERG|
Beginning with PeopleSoft 8, we have three new types of PeopleCode, often referred to in general as "component PeopleCode".
Yes, this may be very old news for you, but today I'd like to make a few quick points about using component vs. record
First, the basics. Record PC is the familar code that you can see by opening a record definition and clicking on the
code button or View | View PeopleCode. (Oh, by the way... As you know, there are four different display views of a record definition.
Each has a toolbar button. They are the Field display, the Use (keys) display, the Edits display, and the PeopleCode display.
Did you know that you can see all of this information at the same time? Position the cursor at the right edge of the "Long Name"
column heading. The cursor will change to two arrows. Double-click there.)
Record PC applies to all components that use the record on one or more pages. If the code must do different things depending
on the component, we need to write something similar to the following:
If %Component = Component.MY_COMPONENT then
Or, you might occasionally still see the older style using
PanelGroup instead of
This construct allows us to run code for one or more specified components.
With component PeopleCode, however, we simply write the code without the IF and it runs only for the component where the code
is stored. To access component PC, open the component definition and then go to View | View PeopleCode on the menu.
When the PeopleCode editor window appears, click on the left dropdown to see
a list of objects: the component, the records used by the component, and the fields on those records. The ones in bold already
have PeopleCode. Click on the appropriate line to view, add or change code. These lines represent three distinct types of
objects: component PC, component record PC, and component record field PC.
Click on the right dropdown to select the
appropriate event. The list of events changes based on the type of code selected.
So, what are the advantages, if any, of using component PC instead of record PC? I can think of a few.
First, it is often more convenient or logical to place code in one of these events. This is especially true with the component-level
PC (the first line in the dropdown list). The component level provides the PreBuild and PostBuild events, which may be better, more
logical places to put code applying to the component—rather than using record-level RowInit or page-level Activate PeopleCode events.
Second, using component PC eliminates the need for the
If %Component construct. This can eliminate some messy code.
Third, record PeopleCode becomes more reusable. Suppose that you create a new record definition and add code to it. If this code applies
only to your component, and someone later needs to use the record in a different component, changes to the existing code will be needed. If you
attach your code to your own component, anyone can reuse the record without making code changes.
But I think that the best reason for using component PC is that it helps to reduce customization of existing programs. When you
create a new component and use an existing record, it is better to create new component PC programs as needed than to change the
existing code. Don't try to minimize the number of PeopleCode programs. Adding new programs reduces customization (that will
need to be analyzed during the next upgrade) and simplifies migrations.
However, there are some disadvantages too. If you find that you are adding the same or similar code to every component, it may
be better to put it into the record definition and share it instead. There are similar events, and so we need to be aware of the
order in which they fire (record PC goes first). Also—and this is a minor criticism—component PC seems somehow
less "obvious", a little more "hidden" than record PC and just a little more difficult to find. Over time, though, as all developers
become more comfortable with using it, that should no longer be a consideration.