Foglight 6.0.0 - Web Component Guide

The Edit Module popups

Click the triangle icon () at the right of a system module name and a menu appears.

The choices are:

Validating Modules

You can validate a system module and check all the definitions within it for errors or warnings. Click the small triangle at the right of the module’s name in the module definition pane and choose Validate. This is useful for catching errors that might have crept in through hand coding or prior incompatibilities in the WCF tooling that allowed poorly-configured views to be saved. This functionality can be invoked from the module’s menu.

There is a Clean up option that can be used to remove unused resources.

The other choices in the popup shown by clicking the small triangle at the right of the module’s name are Edit, Delete, and Add Submodule. Clicking Edit launches a dialog box that allows you to assign relevant and allowed roles to the module, which lets you control its visibility and its access rights.

Definitions and Entities

Definitions are the configurable units in Web Component Framework. They include Views, Queries, Functions, Renderers, Tasks, Type Mappings, Type Mappings and Theme and Module Resources.

Entities are the types of definitions that can be referred to by an ID identifier in other definitions. Views, Queries, Renderers, Tasks, Type Mappings are entities.

NOTE: Views and their properties are described in the Web Component Reference.

Marking an Entity as public indicates that it can be used by any definition in any other module. For this reason the editors do not allow you to delete a public entity. However, you have the option of replacing a view containing a public entity.

Entities that are not public can only be referenced by definitions that have a shared module ancestry. Definitions have a shared module ancestor if they have a parent, grandparent, and so on, module that is the same or one is an ancestor of the other.

Only public entities are shown in modules that do not have a common ancestry with the module containing the current definition. Keep this in mind when attempting to select an entity, especially if you think one should be there and it isn’t.

When copying entities, whether entities are public or not needs to be taken into consideration.

You can make a shallow copy of an entity that is not public. However, if that entity refers to a non-public entity, that is, refers to a query via a Query Binding, then the copy will not be allowed if that non-public entity is not accessible from the target module to which you want to save the copy.

The View’s deep copy feature can be used to copy a view that references a non-public entity that is not accessible from the target module. However, a warning message will be issued that the inaccessible, non-public entity will be copied and the reference will be changed to refer to the copy. This may not be what you want. You may actually want the references to be maintained because you intend to deep copy a view to a temporary module, make the desired changes to the view and its related entities, and then deep copy the view back to its original module.

You can perform either a copy of the view or a deep copy of the view without having to use the Add View work flow to invoke the copy. Moreover, if you wish to do a simple copy, but are not permitted to because of private reference restrictions, then a deep copy can optionally be invoked to minimize the duplication required to copy the specific view.

Entities that are not public may be moved to another module that has a common ancestry. Movement is restricted to such modules because the entity may have a reference to another non-public entity and thus only if it is moved to a module with common ancestry would that reference remain allowable. The tree of target modules that an entity may be moved to reflects this restriction. The only modules that are selectable in the tree are those to which the entity may be moved.

Function and Query Entities can be unit tested. When you select a Function or a Query in the Definitions Editor, a Unit Tests toolbar button is available. When you click that button, a dialog box appears, allowing you to create, edit, remove, and run unit tests.

NOTE: A dashboard is available in the Dashboard Support module that allows you to run multiple unit tests.

Writing unit tests

Unit tests have three attributes:

Unit test scripts have a TestHelper class available to them. It contains useful methods for unit tests.

For functions, the testHelper is an instance of FunctionUnitTestHelper. For queries, the testHelper is an instance of QueryUnitTestHelper.

The only difference between these two helpers is that the invoke(Object... arguments) method has different return types and throws different exceptions.

Noteworthy test helper methods are listed in the following table.

Observations

In general, the Web Component Framework and Foglight® are concerned with the collection of information over time. These collections are called observations. Observations can be of any kind of object. Observations that are handled specially by the Web Component Framework are Metrics and Enum Observations. The scope and quality of the information returned by an observation in the Web Component Framework is determined by the time range used to retrieve the information.