Welcome Guest Login SignUp

Home

Technical

Functional

CNC

AS400

DB2

    Citrix

JDE News

Live Radio

Feedback

JDE Forum Comments/Reviews/Queries
153 day(s) ago   #352
Name: Admin1
Category: Technical
Location: Singapore
Date: 2019-12-29 12:59:17
Replies(0)

Status:
  #352

Power Forms in JDE E1

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.


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: - 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 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.

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.

Post Comments/Queries
Email:*
Name:*
Details:*
 
   
* Required Entry Field(s).  * Your comments may subject to varification.  * Your email ID will not appear in the forum.
 
Disclaimer: Most of the posts in this blog cater solutions/suggestions/workaround to issues for specific tools release or JDE E1 version and are just information only. Please be carefule while applying it in your environment. JDEthread will not be responsible for any data loss or spec corruption (if any).
Copyright © 2010 - 2020 JDEthread.in