| Identifying Custom Objects | KEVIN RESCHENBERG
06-01-2004 |
Today I'd like to talk about a very simple topic that leads into a somewhat more complex one.
Here's the simple recommendation: Choose and use two "unique identifiers" for your customization.
The first unique identifier is a series of characters that should be a part of a custom object's name. When
you create a new custom object (not simply when you modify an existing object) and give the new object
a name, the name should include your unique identifier. This applies to just about any object that has
a name but does not require a specific format for the name. For example, you would want to use this for
records, fields, pages, and SQRs...but not for PeopleCode (which doesn't really have a name) or "DP"
permission lists.
If you work for X Company, you might use "X_" in the object name. But if you work for ABCD Company,
do not use "ABCD_". It's too long. We have very limited space for naming certain types of objects.
In a case like this, you might just use something arbitrary such as "Z_" instead. Similarly, if you
work for HR Company and you are installing an HRMS system, don't use "HR_"! Look at some of the existing
objects and choose one or two letters that are rarely used.
Should this identifier be at the beginning or the end of the object name? From the examples given above, you
can see that I prefer placing it at the beginning. Placing your unique identifier at the
end of the name does have the advantage of allowing the list to sort related objects together. For example, if
you have a new custom version of the existing object DEPT_TBL and call it DEPT_TBL_X, the two objects will
sort together. However, this is not much of an advantage since the objects we are talking about here are the
new custom objects that you will create. Most of these will have little or no connection with existing,
PeopleSoft-delivered objects. Rather than always searching for custom objects by using "%X" in the search specification,
it is easier to find the objects if you place the identifier at the beginning of the object name. Then any
search results will group all of these objects together.
What about objects that are being modified rather than cloned? Should you automatically change their names to reflect the
fact that they have been customized? No. I'll deal with the "clone or modify?" question in a
future post. That's the "somewhat more complex" topic I mentioned earlier.
The other unique identifier you will need is for comments within objects. This applies to PeopleCode, SQR, and
any object that has a comments area accessible through the Properties button. You may have other standards for
commenting changes, but at a minimum your unique identfier should appear within the comments. This allows you to
identify custom changes quickly while reading the comments. It also helps you find customization by doing a
"Find In" search, a Windows file search, or even a search of the PeopleTools tables using SQL. This capability is
especially critical during upgrades.
This unique identifier probably won't be the same as the first one. For this one, we don't have the restriction
on the length of the identifier. Choose something that won't occur frequently within delivered code. For example,
X Company should not simply use "X" in comments. "X-CO" or "X Company" might be better. But any arbitrary string
of characters will work as long as all developers can remember it easily and use it without misspellings.
"X Company, Inc." would not work unless everyone entered the punctuation in exactly the same way.
Even if you have not been using unique identifiers in the past, it's a good idea to start using them for new
code and objects.
|
