Foglight 7.1.0 - Web Component Tutorial

Main View: The view that is to be displayed by selecting the module in the Dashboards tree. By specifying a Main View, the module name itself becomes active. You can use this functionality to provide a shortcut to the most frequently chosen dashboard in the module.

•

Delete: Deletes all the view components in the module. You are warned that this operation cannot be undone.

•

Validate: Runs tests on the module to check such things as unused context entries. You can choose to run validity checks on all the module’s components, or just a selected set. For instance you could choose just the queries and the functions for testing. A report shows the result of the validity check.

•

Set as Working Module: Sets the module as the working module. This module becomes the active module when you navigate to the Definitions area.

•

Cleanup: Removes unused resources from the module.

•

Add submodule: Creates a sub-module entry so that it appears under the current module

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.

Public Entities

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.

Copying Entities

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.

Moving Entities

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.

Unit Testing Entities

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:

•

name: The name of the test. Must be unique per function/query.

•

timeout: The maximum time (in seconds) that the unit test is allowed to run. If the test exceeds the maximum, then the run will be stopped automatically

•

script: The script of the unit test.

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.

Table 1. Test helper methods
Method	Description
invoke(Object... arguments)	Use this method to invoke the function/query being unit tested. It will take into account the current SpecificTimeRange.
setSpecificTimeRange(SpecificTimeRange)	Use this method to set the current SpecificTimeRange. If a helper method is subsequently called which needs a SpecificTimeRange, a TimeRange or a timestamp, one will be used that reflects the current SpecificTimeRange.
Assertion methods	There are a number of JUnit-like assertion methods for checking conditions in your unit test. For more information, see the FunctionUnitTestHelper and QueryUnitTestHelper API documentation.
checkIfCancelled()	If your unit test can potentially take a long time to run, use this method to check if the test has been cancelled (either by a manual stop or because it has exceeded the TestCase’s timeout).

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.

Please select your product:

To serve you better, please complete the Purpose of your Chat:

Recommended Solutions for Your Problem

Foglight 7.1.0 - Web Component Tutorial

The Edit Module popups

Validating Modules

Definitions and Entities

Observations