COSMOS Design 214794

Back to Data Reporting Design

Change History

Name:	Date:	Revised Sections:
Sheldon Lee-Loy	01/09/2008	Initial version
Sheldon Lee-Loy	01/28/2008	Added mockups

Workload Estimation

Rough workload estimate in person weeks

Process	Sizing	Names of people doing the work
Design	0.2	Sheldon Lee-Loy
Code	3.5
Test	0.5
Documentation	0.5
Build and infrastructure	0.2
Code review, etc.*
TOTAL	4.9

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

Purpose

A generic metadata driven cmdbf query builder will provide a convinient way for users to construct cmdbf queries. The query builder should provide extension points to allow the customization of the builder.

The service meta-data introduced in CMDBf1.0 can be used in this case to prompt the user with only what is supported by an MDR. In case an MDR does not provide meta-data, then all constraints should be enabled. The meta-data can be used to determine

  1. Support for relationship cardinality and depth limit
  2. Support for constraints
  3. The operators supported on a property value constraint
  4. XPath dialect support
  5. Record types supported 

As a result the generic query builder should query the MDR to determine what kinds of query the user can build.

Design

The initial focus of this design should support all query directives. The query builder is a single dialog box that has two sections. The left section of the dialog box is composed of a tree that shows the element structure of the cmdbf query. The right side of the dialog box shows detail informatoin of the selected element. The user would add and remove elements left side of the box via at ree widget while modify element attributes on the right side of the dialog box.

The kind of elements that can be added is contrained by the service meta data of the MDR that is being queried. Similarly the type of attributes that can be modified or created are also dictated by the service meta data. This is illustrated in the next section.

Mockups

Mockup Update

Widgets

From the previous illustrations one can see that the CMDBF query builder is composed of four main widgets

• Dialog Widget - composite widget that is composed of a tree widget and grid widget
• Tree Widget - tree widget that the user can add and remove nodes
• Grid Widget - various flavors of a table widget that the user can edit
• Context Menu - menu that is shown to add and remove nodes within the tree

Dialog Widget

This is a simple dialog widget that lays out the Tree Widget and Grid Widget. This widget should also contain buttons to submit or cancel. The responsibility of this widget is as follows:

• layout widgets
• construct the overall cmdbf query based on the user input
• submit the cmdbf query

Tree Widget

This is a simple tree widget that shows the structure of the cmdbf query structure. The responsibility of this widget is as follows:

• shows the structure of the tree.
• send notification to the grid widget when the user selects a node
• holds the json structure of the cmdbf query. That is, the data store of the tree should mirror the structure of the cmdbf query

Each node in the tree should be tagged depending on the type of the node. The following shows a sample json structure that can be used to represent the root level elements:

{ identifier: "object",  label: "title",  items:[
                 {title:"elementTemmplate",nodeClass:"elemType",object:"1"},
                 {title:"elementTemmplate",nodeClass:"elemType",object:"2"},
                 {title:"relationshipTemmplate",nodeClass:"relType",object:"3"},
            ]
}

By tagging the elements this will help configure what kind of menu option are available for a particular node in the tree. As a result this is required by the context menu widget.

Grid Widget

On the right hand side of the dialog box provides the ability for the user to edit attributes on various elements. The section of the dialog box is dynamic. In most cases a grid is provided. Some attributes in the grid require either a text box or a drop down list depending on the node that is selected of the service meta data information. Durning the creation of the widget the contents of the service meta data should be passed to the widget.

It should be possible for exploiters to provide their own custom widgets to edit the attributes. The right hand side of the dialog box should provide an extention tag that allows users to plugin their own user interface.

Context Menu Widget

The context menu is very dynamic and changes depending on what nodes are selected and the information stored in the service meta data. The context menu should extend the basic dojo menu context widget. Durning the creation of the widget the contents of the service meta data should be passed to the widget. The context menu will process the service meta data and display the right menu options.

When the user selects a menu option the menu widget will send the json to the tree that will be added to the selected node.

Service Meta Data Outputter

An ouutputter is needed to produce the json representation of the service meta data. This outputter will recieve an epr to an mdr. The outputter will make a request to the mdr for the service meta data and produce the json that represents the service meta data.

Open Issues/Questions

All reviewer feedback should go in the Talk page for 214794.