Bookshelf Home | Contents | Index | Search | PDF

Configuration Guidelines > Configuring the User Interface > Applets >

Creating and Modifying Applets

---

During the initial stages of an implementation, you define the required views. The applets displayed on these views usually fall into one of these categories:

Applets that are standard and do not require any modification.
Applets that closely align with an existing list applet, but require minor configuration such as a title change, inactivating or adding controls or list columns, and changing display labels. For this category, it is recommended that you configure the existing applet object and its child objects.
Applets that represent an already existing relationship (for example, opportunity contacts), but require extensive modification of the existing applet to produce a new applet layout. Modifications are considered extensive if the new applet requires a large combination of different configurations, such as resequencing of existing controls or list columns, inactivating and adding new controls and list columns. For this category, it is recommended that you create a new applet object (by copying an applet that closely resembles the applet you want to create), and then modifying the copied applet. The resulting configuration will be much cleaner and easier to maintain and upgrade (both manually and automatically).
You may need an applet with different drilldowns in different views.
Applets that do not have an equivalent existing applet. These tend to be applets that expose a new business component. Always create a new applet for this category of list applet.

NOTE:  Remember to set the Upgrade Ancestry property on all custom applets that are cloned from another applet.

Modify, rather than copy, an applet, unless you are making extensive modifications to the applet. This avoids having to change all references of that applet to the new copy.

The following are examples of situations in which you might need to copy an applet:

When you must extensively modify an existing applet.
When you need a Read Only copy of an existing applet.

NOTE:  Do not change the Class property of preconfigured applets.

The objective of your design and configuration projects should be to produce a consistent and intuitive user interface. Wherever possible, applets displaying the same business component should be consistent across different screens and views. For example, the contact list displayed for an opportunity should be consistent with the contact list displayed for an account. Whenever possible, reuse applet definitions between different views and screens. Obvious exceptions include redundant controls or list columns and controls, or list columns that are relevant only to the current parent business component. For example, you would display the contact's account information when displaying opportunity contacts, but not when displaying account contacts. This recommendation does not necessarily apply when comparing list with form or entry applets. When the screen space for a view is limited, it may be practical to include fields at the end of a list applet that are not displayed on the associated entry applet.

Another approach to increasing the number of fields available in a form applet is to use applet toggling. You can define two applets based on the same business component to show information from the same record (but the field controls are distributed over multiple applets) and the user can toggle between the two.

Bookshelf Home | Contents | Index | Search | PDF