Using Page Controls in Deferred Mode

Edit Tables

Set fields that have edit table validations to deferred. The user can click the Refresh button for immediate validation of the field; otherwise, the prompt validation is deferred until the next required transmission to the application server.

Prompt Tables

Use deferred processing for prompt table edits that use %EditTable to set the prompt keys based on the values of other fields on the page. Deferred processing still results in the appropriate behavior being run. For example, if the user clicks the prompt icon, the system:

Determines which fields have changed since the previous server transmission.
Runs the appropriate PeopleCode events.
Applies the values from the page to the buffer.

This action results in setting the correct values before resolving the %EditTable function, provided that any controlling fields come before the prompt table edit based on the page layout order.
Runs the prompt table edit lookup logic for the corresponding field.

Drop-Down List Boxes

Do not use drop-down list boxes when the high-order key values are set on the same page. If you do, it requires the server to transmit the correct drop-down list box values based on the high-order key values. Therefore, set the high-order keys on another page, if possible, or use a prompt lookup instead.

For pages that have an effective-dated scroll area and a drop-down list box based on the PSXLATITEM translate table, the drop-down list box is not refreshed when the effective date is changed on the page. However, the drop-down list box does accurately reflect the new effective date the next time that the page is displayed. Evaluate whether this is a problem for the transaction, based on whether customers typically enter effective-dated XLAT rows for the field and on how often changes to the XLAT values are made. If this is an issue, either replace the drop-down list box with an edit box and a prompt, or use the refresh icon after the effective date field.

Drop-down list boxes are a good design choice because they present users with a small number of selections from which they must select one. They are typically more appropriate than prompts for transactions that are targeted at casual, untrained users. Prompts are more appropriate when a power user is entering the transaction from a paper form or document that contains the necessary codes.

Check Boxes and Radio Buttons

Remove any FieldChange PeopleCode associated with check boxes in a grid that are mutually exclusive (meaning only one row can be checked). Instead, implement cross-validation edits in SavePreChange PeopleCode. When you design cross-validation edits between a radio button or check box and any associated edit box fields, assume that the controlling field (in this case, the radio button or check box) is correct.

Related Displays

When you include related displays on your pages, make sure that they are set to deferred mode and that the standard Refresh button is enabled. Then, users can press the Refresh hot key to display related displays when they want to see them. Self-service transactions should not display the code and corresponding related display; they should use descriptive prompts.

Adding Multiple Rows

This feature enables the user to specify the number of blank rows to be added when clicking the Insert Row button.

The number of blank rows that the user specifies is included on the page when it is refreshed, so application server processing is no longer required to add individual rows.

Do not use this feature for effective-dated grids or scroll areas.

Multiple row inserts might not apply if the entire row is populated using PeopleCode, especially if the data is copied from previous rows. If a multiple row insert does apply, the default value of the ChangeOnInit property can be used. (The default value is True, which means that any PeopleCode updates done in the RowInit or RowInsert events set the IsChanged and IsNew properties to True.)

After a transaction is saved, empty rows are discarded before the page is displayed again to the user. An empty row means that the user did not access the data and that PeopleCode or record defaults might have been used to initialize the row for the initial display.

PeopleCode Save processing (that is, SaveEdit and SavePreChange PeopleCode) runs for all rows that are in the buffer (including the empty ones). Therefore, SaveEdit and SavePreChange PeopleCode should be coded so that it runs only if the field contains data or if the row properties IsNew and IsChanged are both true.

An alternative method is adding PeopleCode in the first save program in the component to explicitly delete any row based on the IsNew and IsChanged properties. If you choose this method, then rows should be deleted from the bottom of the data buffer to the top (last row first).

To implement multiple row insert:

Ensure that deferred processing is set.

Open PeopleSoft Application Designer and ensure that deferred mode is set for the component, all pages in the component, and all fields on each page.
Access the Page Properties dialog box of the appropriate control.
Enable multiple row insert.

For each grid or scroll area where appropriate, select the Allow Multi-row Insert check box under the Use tab in the grid or scroll area property sheet.
Add ChangeOnInit PeopleCode.

Setting the ChangeOnInit property for a rowset to FALSE enables PeopleCode to modify data in the row set during RowInit and RowInsert events without flagging the rows as changed. This functionality ensures that only changes entered by the user cause the affected row to be saved.

Note:

Each rowset that is referenced by a grid or scroll area with multiple row insert enabled should have the ChangeOnInit property for the rowset, including child or lower-level rowsets, set to False. In addition, you must set this property before any RowInsert or RowInit PeopleCode for the affected row.