Power Forms

Power Forms

A power form is a web application form that enables users to view multiple, interrelated views of data, grids, and tab pages on one form and to pass logic among them. The tab pages can have their own business views, and these business views can communicate with each other and can update data based on selection and changes that occur in other business views on the form. Power forms are designed for advanced end users.

Advantages:-

Multiple views on a form.

Multiple grids on a form.

Multiple tab controls on a form.

Tab pages with their own business views.

Business views that communicate with each other and are updated based on selection and data changes that occur in other views on the same form.

 Power Form Types

 The types of power forms are:

 • Power Browse.

 • Power Edit.

 • Reusable Browse subform.

 • Reusable Edit subform.

Power Browse Form

 Similar to a Find/Browse form, a Power Browse form is designed  only for browsing data. Editing capabilities are not available on  this form.

  Power Edit Form

 Similar to a Headerless Detail form, a Power Edit form is  designed for browsing and manipulating data.

 Reusable Browse and Edit Subforms

 Reusable subforms are discrete objects in the system that  represent one data view. Reusable subforms are referenced through  other applications with aliases. Subforms own the data flows    between the interface and the database.

Power Form Performance

 Power forms work best when you use an object-oriented design to  create them. When you design modifications or applications, you  need to identify objects (subforms), how the objects interact  with each other (business logic or actions), and when their  attributes (variables or fields) interact or change (states).  This design is necessary to minimize the data passed between  parent and child forms.

Power Form Key Standards

 When using Power forms and subforms to create an interactive application, follow these key standards:

 • Do not implement search and edit use cases on the same form.

 • Avoid toolbars on Power forms.

 If your application includes a hierarchical layout of subforms and these subforms include push buttons, do not use the toolbar. Hide the toolbar and provide form and subform level push buttons instead. Toolbars should be avoided as much as possible in 8.12 applications

 • Follow a standard naming convention.

 For example: <Application Title> - <Verb> <Object Name> for Requisition Inquiry - Search for Requisitions.

 • Title all subforms, unless they contain tabs.

 • Name grids so that the displayed information is clearly identified, unless the grid appears alone on the form.

Power Form Types

 The Power Browse and Power Edit forms have extended functionality when subforms are embedded or referenced. Using power forms to create applications has many advantages. For example, applications are usually characterized by a sequence of forms. Typically, a user launches an entry form and then, to update information or find related data, must navigate through a series of interconnected forms. Power forms eliminate these navigations by enabling the developer to place subforms on power forms.

The general properties of Power forms are:

• All regular controls except a parent-child control can be placed on a power form.

• Multiple tab controls are permitted.

• The maximize grid feature is supported for all grids.

• Power forms contain both vertical and horizontal scroll bars.

• Only power forms can contain subforms.

• Power forms run only on the web.

Power Browse Form

The Power Browse form enables:

• View-only.

• Subforms.

Power Browse forms with a business view should always have a grid with at least one column.

Power Edit Form

 The Power Edit form enables:

 • Data modification.

 • Data browsing.

 • Subforms.

Power Edit forms without a business view have the characteristics of a Headerless Detail form. Power Edit forms with a grid enable users to update and enter multiple records simultaneously.

 The Power Edit form enables:

 • Data modification.

 • Data browsing.

 • Subforms.

 Power Edit forms without a business view have the characteristics of a Headerless Detail form. Power Edit forms with a grid enable users to update and enter multiple records simultaneously.

  Subform Types

 The two subform types are:

 • Standard subforms.

 • Reusable subforms

Subforms can exist as discrete objects in the system. You can place the subform itself on a power form; this action is referred to as embedding. You can also reference an existing subform on a power form with an alias; this action is referred to as reusing. Typically, you reuse subforms that are designed to appear on numerous forms, such as the display of address book information. In this way, you can more easily standardize the interface.

Reusable Subforms

 A reused subform is actually just a pointer; therefore, it is unaware of its parent and children in any given context. If you want a reused subform to communicate with its parent or children, you must do so through ER. While you cannot embed a subform within another subform, you can reuse a subform within another

subform. In other words, you can embed or reuse a subform within a reusable subform, but you cannot embed

or reuse a subform within an embedded subform. Inserting reusable subforms in a form is different from inserting an embedded subform. They exist as two different control types in the user interface. Therefore, the FDA Menu/Toolbars contain two different insert actions. If you insert an alias, you are prompted for the application. If you insert a reusable subform, you are prompted for the subform. You cannot insert a subform onto a form until the application the subform has been defined in has been saved. Reusable subforms can be written once and then reused in any other power form. They are created as their own entity within an application. The different types of reusable subforms are Browse and Edit.

  

A subform is a control designed for use on a power form or another subform. Although technically a control, subforms have some form characteristics as well. Each subform represents one data view. That is, each subform control can have a single business view (BSVW) attached to it. Power forms can contain several subforms, so a single power form with multiple subforms enables users to see multiple data views. For example, a user selecting a purchase order in a grid could see related shipping information in one subform and fulfillment information in another subform on the same power form. When the user selects a row in the grid, all of the data is updated. Most importantly, the user does not have to open a new form to see the updated data.

 Together, power forms and subforms provides you with the ability to code:

 • Multiple views on a form.

 • Multiple grids on a form.

 • Multiple tab controls on a form.

 • Tab pages with their own business view.

 • BSVWs that can communicate with each other and even react to selection and data changes that occur in other views on the form.

  

Processing Of power forms:-

Power Browse:-

 When a Power Browse form is called, runtime initializes these items in this order:

1.   Thread handling.

2.   Error handling process.

3.   Business view columns.

4.   Form controls (FC).

5.   Grid fields.

6.   Static text.

7.   Help.

8.   Event rule structures.

Events

 The Power Browse form supports these events:

 • Dialog is Initialized.

• Post Dialog is Initialized.

• End Dialog.

• Grid Record is Fetched.

• Write Grid Line-Before.

• Last Grid Record Has Been Read.

• Write Grid Line-After.

• Row is Selected.

• Notified By Child.

  

Power Edit Form

 When a Power Edit form is called, runtime initializes these items in this order:

1.   Thread handling.

2.   Error handling process.

3.   Business view columns (BC).

4.   Form controls (FC).

5.   Grid fields.

6.   Static text.

7.   Helps.

8.   Event rule (ER) structures

Events for a Form with Grid Control

 These events can occur on the Power Edit form during runtime if the form contains a grid control:

• Dialog is Initialized.

• Post Dialog is Initialized.

• Grid Record is Fetched.

• Last Grid Record Has Been Read.

• Clear Screen Before Add.

• Clear Screen After Add.

• Write Grid Line-Before.

• Write Grid Line-After.

• Post Commit.

• Notified by Child and End Dialog

Events for a Form without a Grid Control

 These events can occur on the Power Edit form during runtime if the form does not contain a grid control:

• Dialog is Initialized.

• Post Dialog is Initialized.

• Clear Screen Before Add.

• Clear Screen After Add.

• Add Record to DB - Before.

• Add Record to DB - After.

• Update Record to DB - Before.

• Update Record to DB - After.

• Post Commit.

• Notified by Child.

• End Dialog.

When you place subforms on a power form or another subform, the system treats the interactions among them as parent-child relationships. The power form or subform acts as the parent, and the subforms act as the children of the power form and as siblings to each other. This hierarchical relationship governs logical relationships. It is also represented visually in the Form Design Aid (FDA) application tree view as a hierarchy to help you understand the relationships.

Similar to a form, a subform owns the data flows between the interface view and the database, including browse, insert, update, or delete. In fact, you create a subform as if it is a form, and then you place it as a control. Do not let its appearance fool you: a subform is really a control, and the FDA interface treats it accordingly. For example, if subform B is contained in power form A, then when you select B the FDA control bar still displays the title of A. Additionally, if you view the data structure, you will see the data structure for A and not for B.

Hierarchical Structure

The two hierarchies in FDA are:

• Control hierarchy.

• Business view hierarchy.

Control Hierarchy

In this hierarchy, controls are contained within other controls.

 Business View Hierarchy

 The business view hierarchy enables you to connect business view containers (subforms) to each other. Subforms can only interact with their parent and their children. This hierarchy should be created based on relationships between business views. Data flows between parent and child in the business view hierarchy. There is no direct data flow among siblings or from the power form to the grandchild subform

Transaction Boundaries

 Power forms include the transaction property, which functions in the same way with other form types. By default, the transaction property is scoped to OK  button processing; however, the scope can be extended to business functions, table input/output (I/O), and form interconnects.Subforms are scoped to Save button processing; however, the scope can be extended to business functions, table I/O, and form interconnects. When you include all forms in the transaction boundary and the roll back data on any one form, the system rolls back the changes on all of the forms