Some Strengths And Weaknesses Of PeopleTools

Strengths of PeopleTools:
Extensive Support for Effective Dated Logic
Built in Security Model/Framework
Navigation Built In
Rapid Development
Platform independence

Weaknesses of PeopleTools:

No Usage Tools
Long Learning Curve
Proprietary JavaScript Libraries
No Version Control

References:
strengths-and-weaknesses-of-peopletools

Rules for Buffer Allocation and enhancing performance

When a user chooses a search key from the search page, the component processor will build a set of SQL statements to retrieve data from the database and store it into the buffer.

The component processor uses a specific set of rules to do this. If a field from a record is referenced on a page, then all fields/columns from that record definition and all rows that are subordinate to the search key are retrieved into the component buffer.

There are, however, a few exceptions to this rule. The first exception has to do with the data at level 0. If the only fields at level 0 are the search key and alternate search key,then the component processor will only retrieve those fields and not the entire row. However, if there is at least one field that is not a search field on the page at level 0, the component processor will retrieve the entire row and load it into the buffer.The second exception deals with related fields. If you have a related field on the page, the component processor will only retrieve that field from the database and place it in the buffer. It will not bring in any other columns or rows from the record definition associated with the related display.Other fields may also be retrieved. These fields consist of the following types of fields:

• Derived/Work Field

• Translate Table Field

If an entire row of data was brought into the buffer, any PeopleCode program on any field event within that record definition may be accessed and executed. Here are a few other rules for PeopleCode and the buffer allocation.
• If derived/work fields are brought into the buffers, any PeopleCode on that specific field maybe performed.
• PeopleCode on the related/display record definition is NOT performed.

If the component processor retrieves all of the data that is subordinate to an occurs-level (say all the records at a level) or when it can’t find any more child record definitions, it will retrieve the next row of data at the current occurs-level. It will continue to work its way down through the occurs levels.

If it is at all possible, I highly advise you to use views as the primary record of scroll areas.Using views eliminates the need for related displays and can enhance PeopleCode efficiency.

PeopleCode Insert/update to a record

If All(&str_var1, &nbr_Num1, &nbr_Num2, &str_Var2, &d_Date1, &b_Exists) Then
   &REC = CreateRecord(Record.MY_RECORD);
   &REC.OPRID.Value = %OperatorId;
   &REC.FIELD1.Value = MY_RECORD.FIELD1.Value;
   &b_Update_Flag = &REC.SelectByKey();

   &REC.OPRID.Value = %OperatorId;
   &REC.FIELD1.Value = BITW_PERSON_DTL.FIELD1.Value;
   &REC.FIELD2.Value = MY_RECORD.FIELD2.Value;
   &REC.DATETIME_STAMP.value = %Datetime;

   If &b_Update_Flag Then
      &REC.Update();
   Else
      &REC.Insert();
   End-If;
End-If;

Installation Table

When you make a change within the Installation Table, you must sign off all clients, stop and restart your application server, and then sign back on again to have the change take effect

PeopleCode events: Did you know?

1. The Activate event is valid only for pages that are defined as standard or secondary. This event is not supported for subpages. 

2. SearchInit and SearchSave events will only execute if the Allow Search Events for Prompt Dialogs checkbox is selected for the search key’s record field properties in Application Designer. 

3. FieldChange PeopleCode is often paired with RowInit PeopleCode. In these RowInit/FieldChange pairs, the RowInit PeopleCode checks values in the component and initializes the state or value of page controls accordingly. FieldChange PeopleCode then rechecks the values in the component during page execution and resets the state or value of page controls.

To take a simple example, suppose you have a derived/work field called PRODUCT, the value of which is always the product of page field A and page field B. When the component is initialized, you would use RowInit PeopleCode to initialize PRODUCT equal to A × B when the component starts up or when a new row is inserted. You could then attach FieldChange PeopleCode programs to both A and B which also set PRODUCT equal to A × B. Whenever a user changes the value of either A or B, PRODUCT is recalculated.

4. The FieldFormula event is not currently used. Because FieldFormula PeopleCode initiates in many different contexts and triggers PeopleCode on every field on every row in the component buffer, it can seriously degrade application performance. Use RowInit and FieldChange events rather than FieldFormula.

5. Deleting All Rows from a Scroll Area

When the last row of a scroll area is deleted, a new, dummy row is automatically added. As part of the RowInsert event, RowInit PeopleCode is run on this dummy row. If a field is changed by RowInit (even if it’s left blank), the row is no longer new, and therefore is not reused by any of the ScrollSelect functions or the Select method. In this case, you may want to move your initialization code from the RowInit event to FieldDefault.

6. Do not use Error or Warning statements in RowInit PeopleCode. They cause a runtime error.

Do not put PeopleCode in RowInsert that already exists in RowInit, because a RowInit event always initiates after the RowInsert event, which will cause your code to be run twice.