Skip Headers
JD Edwards EnterpriseOne Tools Development Tools: Form Design Aid Guide
Release 8.98 Update 4

Part Number E14706-02
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

13 Understanding Portlet Forms

This chapter contains the following topics:

13.1 Portlet Design Considerations

A portal is an application that aggregates portlets into pages and provides authentication, authorization and administration tools. A portlet is a single piece of portal content; it is the window through which users interact with the application while using a portal. Portlets provide information and act as gateways to full-blown applications. Portlets cannot communicate to one another, only to an application.

The principle value of a portlet to a user is that, compared to launching an application and searching for data manually, a portlet can significantly shorten the number of clicks required to get from the portal to the desired information or transaction.

13.2 Portlet Types

This section discusses the three portlet types:

13.2.1 Portlets that are Alerts

These types of portlets are typical of "dashboard" portal configurations used for business intelligence. They show a single dimension of data, provide a description for that data, and have a threshold value, which is often user configurable. If the threshold is breached, some event usually occurs to alert the user to the condition.

As a rule of thumb, limit each portlet to a single data dimension. Users who want to monitor several dimensions should have several portlets available on their portal—one for each dimension to be monitored.

Often, these types of portlets also provide a link to a transactional application that enables the user to see more detail and then change the situation that has caused the alert. If you provide such a link, be sure to prepopulate the transactional application with the data driving the portlet display result. Ideally, the user should not need to perform any queries for the initial data view when the application launches.

13.2.2 Portlets that are Menus

These types of portlets contain task-based links and shortcuts to web locations and applications. The value of such portlets is that the links should be highly tailored to the job role. The links you create to applications should therefore preload as much data as possible, based on the user's role. The idea is to reduce the amount of repetitive data entry the user must perform before entering a frequently-used application.

For example, a sales representative might want a portlet with a menu comprising his or her top 10 accounts. By clicking an account, the user launches an application in a view that shows an overview of all account activity for the last three months.

13.2.3 Portlets that are Shortcuts

These types of portlets facilitate information lookup. Typically, they accept a limited amount of information, one or two fields of data. Just as with menu portlets, you should build in as much as possible based on the job role of the user to reduce data entry and target the result set as much as possible.

Frequently, these types of portlets display the results in an application, not the portlet itself. However, the application is often one that facilitates filtering the results and is not necessarily a full-blown transactional application. Based on your context, you might want to make it easy for the user to launch such an application from the filtering view.

13.3 Understanding Portlet Forms

This section discusses:

13.3.1 Portlet Form Features

Portlet forms are the form types you use to create portlets intended for use in the Oracle Portal or the Collaborative Portal.

Note:

Portlet forms are supported in JD Edwards EnterpriseOne version 8.11 and might not function correctly in older versions of the software.

Portlet forms have these general characteristics:

  • All regular controls can be placed on portlet forms.

  • Multiple tab controls are permitted.

  • Toolbar and form/row exits are not permitted on a portlet form.

  • You must add action buttons to a portlet form.

    No default action buttons are defined by Form Design Aid (FDA).

  • Default actions can be placed anywhere on the portlet form.

  • Portlet forms do not contain scroll bars; you must display all controls within the form.

  • Portlet forms support the Fetch on Business View and Update on Business View form property options.

  • You can nest reusable and embedded subforms in portlet forms.

JD Edwards EnterpriseOne Tools provides two types of portlet forms: browse portlets and edit portlets. Browse portlets enable the display of and queries for information. Edit portlets enable user edit functions—adding, changing, and deleting table information.

If you include a form interconnection in a portlet, the portal containing it will automatically resize the portlet to its maximum size when the user triggers the interconnection. When the user closes the application, the portlet returns to its normal size.

13.3.2 Portlet Personalization

One feature of portlet forms that is unique among FDA form types is portlet personalization. Users can toggle between standard mode (where they interact with the application) and personalization mode, where they can select different options that affect how the application runs while in standard mode.

For example, say that the application by default displays all accounts that are overdue by 30 days or more. Users might be able to choose instead to view accounts that are overdue by 60 days instead, or by accounts in a certain region that are overdue. Alternatively, they might have an option which displays the information in a summarized format instead of showing all the data you show by default. Personalization values are user specific.

You control what options users have. Every option you provide, be it as simple as a filtering function or as complex as invoking additional functionality, is a data dictionary (DD) item passed in with the data structure. The DD items appear when the user toggles to personalization mode, and the user can trigger them by choosing the options and then returning to standard mode. If you do not include any such items in the data structure, then personalization mode is disabled for that portlet.

Because the available options are based on the form's data structure, those values are passed in by runtime to the form if they have been set.

13.3.3 Portlet Form Events

Runtime provides three events that are specific to portlet form types:

  • Portlet is Initialized

    This event occurs when runtime initializes the portlet form and before it initializes any forms which the portlet might contain.

  • Personalization Applied

    This event occurs immediately after initialization to apply previously-saved personalization data. It occurs again when the user clicks the Save button in personalization mode.

  • Portlet is Exited

    This event occurs when the portlet is unloaded by the container. Typically, this occurs as the user logs out or the session times out.

In addition to the portlet-specific events, portlets support the general events in this table:

Event Browse Portlet Edit Portlet
Grid Record is Fetched Yes Yes
Write Grid Line-Before Yes Yes
Last Grid Record Has Been Read Yes Yes
Notified By Child Yes No
Grid Record is Fetched No Yes
Write Grid Line-Before No Yes
Last Grid Record Has Been Read No Yes
Add Record to DB - Before No Yes
Add Record to DB - After No Yes
Update Record to DB - Before No Yes

13.3.4 Edit Portlet Form Design-Time Considerations

In addition to standard form properties, you can control the transaction boundary for edit portlets. You can choose to process each action (that is, insert, update, or delete) on the form separately (Transaction Disabled), or you can process all of the actions at once (Portlet Only Transaction). Choose the latter if processing each action separately would cause data integrity issues. Transaction processing for edit portlets is identical to that for subforms.

13.4 Generating Portlets

This section provides an overview of generating portlets and discusses how to deploy an FDA-created portlet.

13.4.1 Prerequisites

Before you complete the tasks in this section:

  • Create or obtain a portlet application that was created in FDA.

  • Generate the application using eGenerator.

13.4.2 Understanding Portlet Generation

Generating an application based on portlet form types is similar to generating an application based on other form types, the difference being that you must also generate a portlet descriptor file, portlet.xml, that tells the portal which applications are available for the portlet (the WebClient_Portal.war file). This is an overview of the high-level tasks you must complete to create and view a portlet using FDA:

  1. Create an application in FDA using the portlet form types.

  2. Generate the application (that is, the portlet) with eGenerator.

  3. Generate the portlet.xml file into WebClient_Portal.war file with eGenerator.

  4. Install the .war file in Collaborative Portal.

  5. To view it, add the portlet to a page in the portal.

13.4.3 Deploying an FDA-Created Portlet

This section discusses how to deploy an FDA-created portlet so that you can install it in Collaborative Portal.

To deploy an FDA-created portlet:

  1. Launch eGenerator and select Generate, Portlet Deployment.

  2. Select the .war file to generate.

    Typically, the .war file for the local version of Collaborative Portal resides in C:\B9\system\Generator\WebClient_Portal.war.

    eGenerator reads the local specifications for JD Edwards EnterpriseOne and lists all portlets it discovers.

  3. Clear the check box next to any portlet that you do not want to generate, and click the Start button.

    If multiple versions of an application exist, each version is listed.

  4. Select the version you want to generate.

    eGenerator creates a new portlet descriptor file and bundles it into a new WebClient_Portal.war file.

13.5 Updating an FDA-Created Portlet after Initial Installation

This section provides an overview of updating an FDA-created portlet after initial installation and discusses how to:

13.5.1 Understanding Portlet Updates

When you modify an existing FDA-created portlet in FDA, you need only regenerate the JD Edwards EnterpriseOne application to promote the application to the Collaborative Portal. However, if you are removing existing portlets or are adding new FDA-created portlets to Collaborative Portal, you must use eGenerator to update the portlet descriptor, portlet.xml, in the WebClient_Portal.war.

13.5.2 Adding a New Portlet Application

To add a new FDA-created portlet:

  1. Launch eGenerator and select Generate, Portlet Deployment.

  2. Select the .war file to update.

    Select the same war file that you deployed previously.

  3. Clear the check box next to any portlets that you do not want to generate, and click the Start button.

    You should always select all portlets you want to be deployed to Collaborative Portal because after installation, the new WebClient_Portal.war replaces any previous version that exists on Collaborative Portal server.

    eGenerator modifies the portlet descriptor file, portlet.xml, in the .war file.

13.5.3 Deleting an Existing Portlet Application

Regenerating the portlet.xml by removing the portlet definitions does not remove the corresponding portlets from Collaborative Portal when you perform a portlet application update.