Foglight 7.3.0 - Web Component Guide

Types Tab in the Module List Pane

Mappings of icons to data types and mappings of renderers to data types and properties are configured on this tab. When an icon is mapped to a data type, the icon is displayed if an Icon Renderer is specified on any View Property referencing data of that type. When a renderer is mapped to a data type or property, any view property bound to data of the type or property is displayed using the mapped renderer unless a specific renderer is set on the view property.

The Web Component Framework has a concept of renderers for bindings, which can be used to format the output from the binding in various ways. Definitions for all of the renderers are held in a one-file-per-wcf.xml file and in a global file that is common to the whole application. The files are named renderers.xml.

The ID attribute is a unique name that is associated with the corresponding renderer. This is the value that is to be specified in the renderer ID of the binding. See Data .

The optional <associations> section specifies associations between the renderer and sdo types, metric, classes or units, depending on the tags it contains. Each of the tags in the associations section is optional and more than one association of each type may be specified. These associations are used to resolve the renderer when a binding is rendered.

The <configuration> section can be any of the types of configuration mentioned previously. However, each specific class of renderer expects a specific type of configuration.

Unit Mappings

Unit mappings associate renderers to a specific data unit. At runtime, if no specific renderer has been specified on a binding and no renderer has been found in the type mappings, the Web Component Framework looks in the unit mappings to see if a renderer has been mapped to the unit of the data.

Mappings of renderers to units are configured in the Units tab. When a renderer is mapped to a unit any view property bound to data of the unit displays using the mapped renderer. This is unless a specific renderer is set on the property or another renderer is mapped to the data’s type or property.

Tasks

Tasks are logical actions external to the Web Component Framework. Examples in the Foglight realm are tasks for clearing and acknowledging alarms, building a service, scheduling a report, or launching PerformaSure in context on a particular request. The figure demonstrates the selection of a task as the target of a flow action.

Otherwise tasks are configured to behave in the flow in the same manner as views.

The workflow generally looks like:

Some tasks may break the flow – that is, not return. An example of this is launching PerformaSure. In this case the task does not have a flow action that can be configured to update the page.

A task consists of its code and three text files, and is usually packaged in a JAR file.

Tasks are located in META-INF/wcf-metadata/task/X.Y, where X.Y is the Web Component Framework internally generated name for the component.

NOTE: You can use the Execute Groovy Task component to implement a simple task. See the Web Component Tutorial for an example.

Types

If you are building your own complex user interface for some special purpose, you may want to create temporary objects to manage it. You can create your own types in the Web Component Framework.

When building a complex user interface it is common to discover the need to create temporary objects to manage the UI you are creating. You may want to capture input from users to convert later into a more persistent object or to remember choices that a user has made in the past in order to streamline the user’s workflow in the future.

There is a mechanism to allow the creation of types in the Web Component Framework that are specific to the UI mechanism and associated with the modules that contain the rest of your UI artifacts.

Type entities allow you to define types and their properties which can be used in various ways in your UI.