5 Good and Bad Practices

 5 Good Practices

1.     Save as a copy before making changes to a complex page, records and other objects that you can not easily revert in case something goes wrong.

2.     Define a common prefix for all custom objects you are going to create. Preferablly, it should be clients initials e.g. if you are creating a page for Xavier University name the page as XU_PAGE_NAME_PG.

3.     Add Modifications logs and Comments to any PeopleCode you modify. Better, just comment out the statements you need to change and add new PeopleCode. Add proper dated comments to the properties of all the custom objects you created or modified.

4.     Keep component specific PeopleCode to component level. But commonly used PeopleCode should be put at the record level for easy maintenance of PeopleCode.

5.     When compare people objects names against some condition always use ObjectClass.Objectname e.g.

Use %Page = Page.XU_ABC_PG instead of %Page = “XU_ABC_PG”

Use %Componentname = Component.XU_ABC_CMP instead of %Page = “XU_ABC_CMP”

This is because if your object is renamed in later point of time then in the PeopleCode condition it will automatically be replaced with new name if you use ObjectClass.Objectname.

5 Bad Practices

1.     Adding/removing fields to/from PeopleSoft delivered table. Always avoid adding and removing fields to/from a PeopleSoft delivered record. If you need to have additional fields to a PS delivered record, create another custom record with the same key structure as of PS delivered record and add as many fields you like to this custom record. Well, you will never have to delete a field from a PS delivered record. If you no longer require a field, make it invisible on the pages it is being used. This is zero risk approach.

2.     Deleting fields from a delivered page. If you don’t need a field, simply hide it. This makes your life simple and saves you from a lot of trouble.

3.     Adding static labels and texts. Never add static text to a page because such texts are not reusable and need to be translated (in case of multilingual application) and corrected/updated for each page separately. In such cases create a message catalogue entry and use the message on the page. Similarly, if you need to change the label of a field do not put static text. Instead add a new label to the field definition and select this newly created label id on either record field properties or page field properties.

4.     Excessive use of SQLExec. SQLExec should be used only if a particular query returns a single row of data in all cases. SQLExec should never be used in a loop as it hits the database each time it is executed. In such scenario createSQL or getSQL should be used.

5.     Overloading the Page Activate event. Page Activate event should be used only to set the visibility of the different page elements and fields. For other things such as to fill the rowsets on component load, PreBuild or PostBuild should be used.