COSMOS Design 214145

Back to Data Reporting Design

Change History

Name:	Date:	Revised Sections:
Sheldon Lee-Loy	01/07/2008	Initial version

Workload Estimation

Rough workload estimate in person weeks

Process	Sizing	Names of people doing the work
Design
Code
Test
Documentation
Build and infrastructure
Code review, etc.*
TOTAL

'* - includes other committer work (e.g. check-in, contribution tracking)

'** - documentation may span multiple release. Note an additional enhancement is associated with a programmer's guide (ER 210134)

Purpose

A simple generic graph response view is needed catered towards users that are not familiar with CMDBf schemas. This will allow end users to understand and analyze the data easier instead of trying to navigate an XML structure. This view will be used as a default view for the COSMOS UI. This view should be able to render the contents of any graph response in a generic way. There should be extension points to customize the specific contents of the graph response.

Requirement

A table is a likely generic view since users at a glance can determine the number of records in the graph response. A table can scale the cmdbf query response better than a tree since the graph response will most likely be root level heavy (i.e. the tree will contain a large number of root notes rather than many leaf nodes).

As a stretch goal a tool bar should be provided that provides filtering and searching capability. Searching capability may be complicated. Filtering capability can be the definition of a cmdbf query.

Design

Let us first consider the structure of the CMDBf graph response.

Error Handler

The COMSOS UI will define a default error handler object that will be defined as a dojo object. This will allow exploiters to extend or replace the error handler by utilizing the dojo programming model.

The following defines the error handler object:

dojo.declare("cosmos.ui.provisional.error.handler.ErrorHandler", null , {
	constructor: function( keywordParameters){
	},	
 	serverHandler:null,
	//defines a url that will recieve logged messages.
	debug:0,
	//atribute that determins if the message should be logged to the dojo debug console.
	promptDialog:null,
	//defines the dialog box that will show the message.
	prompt:0,
	//attribute that determines if a dialog box should be displayed when a message is logged
	logError:function(message, prompt) {
	// summary: logs an error messages
	// description: the message is logged as an error message.  If the prompt argument
 	//    is set to true a dialog message is presented to the user.
	},
	logWarning:function(message, prompt) {
	// summary: logs a warning messages
	// description: the message is logged as a warning message.  If the prompt argument
 	//    is set to true a dialog message is presented to the user.
	},
	logInfo:function(message, prompt) {
	// summary: logs an informational messages
	// description: the message is logged as an informational message.  If the prompt argument
 	//    is set to true a dialog message is presented to the user.
	}
});

var MESSAGETYPE = {ERROR: 1,INFO:2,WARNING:4,NONE:0}

Logging Messages

Javascript objects that want to log messages would use the "cosmos.log" global variable as follows:

	//log error or informational messages to the debug console
	cosmos.log.debug=MESSAGETYPE.ERROR|MESSAGETYPE.INFO;
	//prompt the user for warning messages
	cosmos.log.prompt=MESSAGETYPE.WARNING;
	//log an error message
	cosmos.log.logError("Error: error message");
	//log an informational message and prompt the user with the message
	cosmos.log.logInfo("Error: error message", true);

Globalization

The error handler will not handle internationalization. It is expected that the messages will be translated before logging the message. Messages can be translated using the dojo globalization programming model (http://dojotoolkit.org/book/dojo-book-0-9/part-3-programmatic-dijit-and-dojo/i18n)

Server Side Logging

The default error handler object provides a means for a server side component to recieve error messages from the client. The client will use the post method to send logged messages from the client to the server side error component. The following define the POST arguements sent in the request to the server component

• message - a string repesentation of the message
• messagetype - this is a numeric value 1,2 or 4 repesenting an error, informational or warning message

Server side logging is further discussed in enhancement 208592

Design Note

Note that the structure of the message is not finalized. The structure of the message is dictated by the overall project error handling strategy.

For example the message structure could model an error code as follows:

{
   errorCode:"MSG010234",
   message: "Connection can not be resolved",
   severity: 40
}