サポートと今すぐチャット
サポートとのチャット

Foglight 5.9.5 - Web Component Tutorial

Using the Web Component Tutorial Tutorial 1: Drag and Drop Tutorial 2: Creating a Dashboard Tutorial 3: Adding a Drilldown Page Tutorial 4: Adding Views Tutorial 5: Using a Grid Tutorial 6: Reports Tutorial 7: Creating a Form Tutorial 8: Renderers Tutorial 9: Adding Questions and Answers Tutorial 10: Sending Messages to Other Users

Sequential headers and footers

The report you create in this tutorial has a host summary page and then a number of pages, one for each host. In a case like this, or if for any other reason you want to have the first page of the report to have a different header than the rest of the pages, there is a solution.

A report can have multiple headers. The reason you placed the header and footer as the first and second component in the PDF Layout’s Views tab was to have them registered by the report generator before any body views. Perhaps the table of hosts in your environment spans more than one page. If the footer is placed after the table component, it does not appear until after the table. In fact this is true even if the table contains only a few rows. The report generator delays emitting the footer until the page after the table is drawn. In the first part of this exercise, there is no page after the first, so the footer does not appear at all.

Therefore, to switch headers or footers, place the new header or footer component before the view that should begin the new page. If necessary, emit a page break between the header and the new component. Using this technique, it is possible to have different headers and footers in all sections of a long report.

Normally, you choose your first body view to fit on page one. But what if you want a new header on the second page and the first page must contain a table or other view that may be several pages long? The first header encountered controls the first page, but if the first body view is several pages long, the header or footer does not change until the whole component is written out. The solution may be to place a thin, empty component after the first page’s header and footer, and then place the next header and footer before the multi-page component. The system places the first header and footer on the first page, emit the empty component, set the header and footer for the next page, and begin emitting the multi-page component. This causes the second and following pages to have the header and footer you want.

Try adding a header for the individual host pages. Place this header component just before the iterator in the PDF Layout Views tab.

Tutorial 7: Creating a Form

This tutorial shows you how to create a form and populate it with data. For the purpose of this tutorial, we use a Form Dialog as a form because this component contains a number of input components and as such can behave like a form. When completed, the end user fills in various input values on the form. In this tutorial, the form fields are placed in a Grid Layout, and the Grid Layout is placed in a Form Dialog container, and clicking the Form Dialog’s Submit button transmits this data to the server. The Form Dialog that we use in this tutorial is called Form for adding a new company manager. The Grid Layout that contains the input controls is called Bean Data Fields for Manager. The Grid has only a few fields, but it illustrates the general idea. A form can have any number of input fields. The dialog supplies the button that initiates the submit action.

•
About this Tutorial
•
Defining the Enumerated Types for Manager and Staff
•
Defining the Manager and Staff Types
•
Defining the Company Type
•
Defining the Functions for Adding and Removing a Manager
•
Defining the Labels
•
Defining the Bean Input Components
•
Defining the Grid Layout
•
Defining the Dialog
•
Defining the Table of Managers
•
Summary

About this Tutorial

This tutorial covers the following topics:

•
Using the Dialog component as a form: The Form Dialog component can be used to perform a batch submit of its data. When used in this way, it is normally referred to as a form.
•
Defining Web Component User Interface Types: If you are building a complex user interface, you often discover the need to create temporary objects to manage the visual components you are creating. You may need to capture input from users and convert it later into more persistent objects, or to remember choices that a user previously made in order to streamline the user’s workflow in the future.
The Web Component Framework allows for the creation of types that are specific to the browser interface mechanism and associated with the modules that contain the rest of your browser interface artifacts.
Type entities allow you to define types and their properties that can be used in various ways in your interface.
•
Using Bean Input components: The Web Component Framework provides a mechanism for collecting user data. The collected data can be stored in context keys and passed from the form that collects them to other views, but for many data fields a much more efficient solution exists by using Bean Input components.
•
Storing or removing the collected data using Groovy function scripts: This tutorial shows you how to create scripts that persist the collected data, but it assumes that you have a working knowledge of Foglight API and that you are familiar with Groovy. It makes no attempt to be a tutorial for the Foglight API or for Groovy.
•
Using a function to control the state of a button: In addition to the four main objectives, an additional activity demonstrates a simple procedure for controlling a button’s Disabled property. The only parameter passed to the function is a number, which is generated by a Context binding that returns the count of all managers by setting the return type to the context’s Count All property.

Anatomy of a form and its design objective

The basic elements of a form are:

•
A Form Dialog component that holds the rest of the form elements. In most cases the Form Dialog contains a grid which in turn lays out the rest of the form elements. To act as a form, the Form Dialog has its Form property set to true.
•
A Grid Layout that holds the form’s input components.
•
Input components placed in the grid. The end user fills in these input components, but rather than firing an action on each input component, the Form Dialog defines a submit action that sends the values of all the input components in one operation. Context keys can be used for a small number of fields, but Bean Input components are much more efficient, especially when there are a large number of fields.
Figure 1. Sample input components

The design objective for the tutorial is to build a data collection utility to hold information about employees. In this fictitious and highly-simplified scenario, one view of a company divides its personnel into managers and staff. The reason for doing this in the tutorial is to have a minimal hierarchy to work with. Thus, the new Data Type to be created in Types will look like this:

 
* 
NOTE: Data Types are described in the Web Component Guide. See the section on Module Types.

Company

•
Managers (list of Manager)
•
First Name (String)
•
Last Name (String)
•
Title (Enumeration: Manager Title, another new Module Type)
•
Employee ID (Integer)
•
Staff Members (list of Staff)
•
... (similar properties, but these will not be used in this tutorial)
Figure 2. Sample hierarchy

This model of a company’s organization is sufficient for the purposes of this tutorial. No attempt is made to capture the way that the company is organized into functional units because that would add unnecessary complexity to the tutorial.

The Web Component Framework imposes a bottom up approach when constructing its entities. If you create the dependent components first, they are available to be referenced by objects at a higher level. That is why, for instance, the enumerated types Manager Title and Staff Title need to be created before creating Manager and Staff types.

関連ドキュメント

The document was helpful.

評価を選択

I easily found the information I needed.

評価を選択