2 Child Screen

This topic provides an overview of the Child screen in the Open Development Tool.

Screens are required in Oracle FLEXCUBE Universal Banking where the base functionality is the same and the differences are either in the layout or in some additional processing that is there are some sets of screens where the majority of the functionality is the same with some variance with existing screens.

Development Workbench supports developing such screens as the child screens of the base function with a facility to upgrade the child screens whenever the base or parent screen changes.

For example, Term Deposit Account Booking, account for term deposit booking will have all the features of a normal customer account with some additional features. Thus it can be designed as the child screen of normal customer account maintenance.

Workbench provides an option to design a child screen as a derivative of a parent screen. Workbench automatically inherits the parent screen and tracks the modifications made in the child screen. Workbench does not allow the developer to delete elements inherited from the parent screen.

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. Oracle FLEXCUBE Universal Banking does not support multi-level inheritance (that is the child of the child is not supported).

Screen Development

Refer to the topic unresolvable-reference.html#GUID-9F352188-1746-4FC6-B9D5-D370BC8B4168 for the screen development.

Generation of Files

The process of generation of files is similar to that of normal function ID. All the units generated for a normal function ID will be generated for the child screen as well. In the script for SMTB_MENU, column PARENT_FUNCTION would contain the name of the parent function ID.

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 STDCUSAC function ID is a normal maintenance screen and STDCUSTD function ID is the child of this screen. The below figure shows the snippet of code from fn_default_and_validate of the child main package.

Figure 2-1 stpks_stdcustd_main.sql


Description of Figure 2-1 follows
Description of "Figure 2-1 stpks_stdcustd_main.sql"

The developer has written defaulting and validation for the parent screen being called before doing validations specific to the child screen. Hence business logic for the parent is reused. The developer has the option to skip doing parent validation for the child screens using skip handlers if required.

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.