Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: for the plan.

Jump to: navigation, search

CosmosDataReportingComponent10 209223

Back to Data Reporting Design

Change History

Name: Date: Revised Sections:
Sheldon Lee-Loy 11/14/2007
  • Initial version
Sheldone Lee-Loy 11/29/2007
  • Added Change History and Workload Estimate sections

Workload Estimation

Rough workload estimate in person weeks
Process Sizing Names of people doing the work
Design 0.5 Sheldon Lee-Loy
Code 0.5 Sheldon Lee-Loy
Test 0.5 Sheldon Lee-Loy
Documentation 0.2 **
Build and infrastructure 0.2
Code review, etc.* 0.2

'* - 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)


There are two tiers to the COSMOS UI.

  • Client-side
  • Server-side

This enhancement will cover the error handling for the client-side tier.


In general the COSMOS UI message logging should adopt similar message logging strategies used by other sub projects. These strategies should satisfy the following requirements:

  1. Provide the ability to log warning, informational and error messages
  2. Provide the ability to replace the logging mechanism with a custom mechanism
  3. Provide the ability to prompt the user with warning, informational or error messages


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){
	//defines a url that will recieve logged messages.
	//atribute that determins if the message should be logged to the dojo debug console.
	//defines the dialog box that will show the message.
	//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.


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
	//prompt the user for warning messages
	//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);


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 (

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:

   message: "Connection can not be resolved",
   severity: 40

Back to the top