1.1.4 Extensible Development for Child screen

This topic provides information on the Extensible Development of a Child screen.

Extensible Development

The developer can add code in hook packages and release specific JavaScript files. The extensible development process is similar to that followed in a maintenance or transaction screen. Refer to respective documents for a detailed explanation. The structure of the system packages will be the same as for a normal maintenance or transaction function ID.

For child screens, in addition to release specific hooks for each logical stage, the system also calls the corresponding hook from the parent function’s programs. This allows the reuse of the common business logic among all the child functions.

For example, Assume UTDENTMN is a normal maintenance screen and UTDTPMN as the child of this screen. Below figure shows the snippet of code from fn_default_and_validate of the child main package.

Figure 1-4 Snippet from utpks_utdtpmn_main.sql



Here u can find that the developer written defaulting and validation for the parent screen is being called before doing validations specific to child screen. Hence business logic for parent is reused. Developer has the option to skip doing parent validation for the child screens using skip handlers if needed.

Note the functions Pr_convert_child_to_master and Pr_convert_master_to_child. These procedures have to be used every time a call is made to the parent function id packages. This procedure prepares object types for the parent and child respectively.