Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "COSMOS Design 214145"

(New page: Back to Data Reporting Design = '''Change History''' = {|{{BMTableStyle}} !align="left"|Name: !align="left"|Date: !align="left"|Revised Sections: |- |Sheldo...)
 
(→‎GraphResponseViewer Widgets Manual Testing)
 
(36 intermediate revisions by the same user not shown)
Line 22: Line 22:
 
|-
 
|-
 
| align="left" | Design
 
| align="left" | Design
−
|
+
| 0.2
−
|
+
| Sheldon Lee-Loy
 
|-
 
|-
 
| align="left" | Code
 
| align="left" | Code
−
|
+
| 2
 
|
 
|
 
|-
 
|-
 
| align="left" | Test
 
| align="left" | Test
−
|
+
| 0.5
 
|
 
|
 
|-
 
|-
 
| align="left" | Documentation
 
| align="left" | Documentation
−
|
+
| 0.5
 
|
 
|
 
|-
 
|-
 
| align="left" | Build and infrastructure
 
| align="left" | Build and infrastructure
−
|
+
| 0.2
 
|
 
|
 
|-
 
|-
Line 46: Line 46:
 
|-
 
|-
 
! align="right" | TOTAL
 
! align="right" | TOTAL
−
|
+
| 3.4
 
|
 
|
 
|}
 
|}
  
 
'* -  includes other committer work (e.g. check-in, contribution tracking)
 
'* -  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 ([https://bugs.eclipse.org/bugs/show_bug.cgi?id=210134 ER 210134])
 
  
 
=Purpose=
 
=Purpose=
Line 63: Line 61:
  
 
=Design=
 
=Design=
−
Let us first consider the structure of the CMDBf graph response.   
+
Let us first consider the pseudo schema 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:
+
 
<pre>
 
<pre>
−
dojo.declare("cosmos.ui.provisional.error.handler.ErrorHandler", null , {
+
<queryResult>
−
constructor: function( keywordParameters){
+
  <nodes templateId="xs:ID">
−
},
+
      <item>
−
serverHandler:null,
+
        <record>
−
//defines a url that will recieve logged messages.
+
        xs:any
−
debug:0,
+
          <recordMetadata>
−
//atribute that determins if the message should be logged to the dojo debug console.
+
              <recordId>...</recordId>
−
promptDialog:null,
+
              <lastModified>...</lastModified> ?
−
//defines the dialog box that will show the message.
+
              <baselineId>...</baselineId> ?
−
prompt:0,
+
              <snapshotId>...</snapshotId> ?
−
//attribute that determines if a dialog box should be displayed when a message is logged
+
              xs:any
−
logError:function(message, prompt) {
+
          </recordMetadata>
−
// summary: logs an error messages
+
        </record> *
−
// description: the message is logged as an error message.  If the prompt argument
+
        <instanceId>
−
//    is set to true a dialog message is presented to the user.
+
            <mdrId>xs:anyURI</mdrId>
−
},
+
            <localId>xs:anyURI</localId>
−
logWarning:function(message, prompt) {
+
        </instanceId> +
−
// summary: logs a warning messages
+
        <additionalRecordType namespace="xs:anyURI" localName="xs:NCName"/> *
−
// description: the message is logged as a warning message.  If the prompt argument
+
      </item> +
−
//    is set to true a dialog message is presented to the user.
+
    </nodes> *
−
},
+
    <edges templateId="xs:ID">
−
logInfo:function(message, prompt) {
+
      <relationship>
−
// summary: logs an informational messages
+
          <source>
−
// description: the message is logged as an informational message. If the prompt argument
+
            <mdrId>xs:anyURI</mdrId>
−
//   is set to true a dialog message is presented to the user.
+
            <localId>xs:anyURI</localId>
−
}
+
          </source>
−
});
+
          <target>
−
 
+
            <mdrId>xs:anyURI</mdrId>
−
var MESSAGETYPE = {ERROR: 1,INFO:2,WARNING:4,NONE:0}
+
            <localId>xs:anyURI</localId>
 +
          </target>
 +
          <record>
 +
            xs:any
 +
            <recordMetadata>
 +
                <recordId>...</recordId>
 +
                <lastModified>...</lastModified> ?
 +
                <baselineId>...</baselineId> ?
 +
                <snapshotId>...</snapshotId> ?
 +
            </recordMetadata>
 +
          </record> *
 +
          <instanceId>
 +
            <mdrId>xs:anyURI</mdrId>
 +
            <localId>xs:anyURI</localId>
 +
          </instanceId> +
 +
          <additionalRecordType namespace="xs:anyURI" localName="xs:NCName"/> *
 +
      </relationship> +
 +
    </edges> *
 +
</queryResult>
 
</pre>
 
</pre>
  
−
==Logging Messages==
+
As stated in the [http://cmdbf.org/schema/1-0-0/CMDBf%20v1.0.pdf CMDBf 1.0 specification document] the graph response is made up of <nodes> and <edges> elements.  Each of these elements have an associated 'templateId' attribute that corresponds to the 'templateId' attribute used to construct the CMDBf query.
−
Javascript objects that want to log messages would use the "cosmos.log" global variable as follows:
+
  
−
<pre>
+
Creating a tab layout will improve the visualization of the node and edge elements. A tab can be constructed for each node or element. The title of the tab will correspond to the templateId.   This will logically separate the edge and node contents.  Color coding or icons can be used to distinguish between a node or edge.
−
//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);
+
−
</pre>
+
  
−
==Globalization==
+
Each tab will contain a table that will show the contents of the node or edge.   
−
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)
+
  
 +
==View Table Mockup==
 +
===Visualizing a node===
 +
The table view will show item and record information.  Note that the node and edges are shown as the top level tabs.  The following mockup follows the sample graph response outlined under the "4.3.2 GraphQuery Response" under the [http://cmdbf.org/schema/1-0-0/CMDBf%20v1.0.pdf CMDBf 1.0 specification document].  Note that the mockup uses a sketching tool used for SWT widgets.  This tool was used to create mockups easily.  The final widget should utilize dojo widgets.  As a result buttons were used to represent the tab buttons.
  
−
==Server Side Logging==
+
[[Image:214145ItemTab.jpg]]
−
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
+
The following user interactions are possible:
−
*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 [[CosmosDataReportingComponent10_208592| 208592]]
+
* When the user selects a row in the item table the record table and additional record type table are populated.  As a result the last tables show the associated records and additional record types.
 +
* The second table that lists the records contains expansion rows that the user can expand or collapse.  When the row is expanded the content of the record is shown.
  
−
==Design Note==
+
===Visualizing a edge===
−
Note that the structure of the message is not finalized.  The structure of the message is dictated by the overall project error handling strategy.
+
The following mockup shows how an edge will be rendered in the view.  The only difference between this view and the node view is outlined in red.  The additional columns will provide information on the source and target mdrs of the relationship.
  
−
For example the message structure could model an error code as follows:
+
[[Image:2141445RelTab.jpg]]
−
<pre>
+
 
−
{
+
The following user interactions are possible:
−
  errorCode:"MSG010234",
+
 
−
  message: "Connection can not be resolved",
+
* When the user selects a row in the item table the record table and additional record type table are populated.  As a result the last tables show the associated records and additional record types.
−
  severity: 40
+
* The second table that lists the records contains expansion rows that the user can expand or collapse.  When the row is expanded the content of the record is shown.
−
}
+
* The user can click on the source or target of the relationship.  At this point the widget will jump to the item that represents the source or target.
−
</pre>
+
 
 +
===Updated Mockups based on user feedback===
 +
[[Image:New214145.jpg]]
 +
 
 +
[[Image:New214145Filter.jpg]]
 +
 
 +
==Widget Design==
 +
<TODO - update text to reflect new mockup/>
 +
 
 +
The CMDBf graph response widget is constructed from several simple widgets.  The following shows the hierarchy of widgets:
 +
*Tab Widget - responsible for rendering the top level tabs
 +
**Item Widget - responsible for rendering the item table lists in the details view
 +
**Relationship Widget  - responsible for rendering the relationship table lists in the details view
 +
*Record Widget - responsible for rendering the record table
 +
 
 +
For each of the above table a data feed is required to get the header information for the tabs and table.  Additional data feeds are required to get the table row content.
 +
 
 +
==Open Issues/Questions==
 +
 
 +
All reviewer feedback should go in the [[Talk:COSMOS_Design_214145|Talk page for 214145]].
 +
 
 +
==Update Mockup==
 +
The following is a running mockup of the graph viewer based on feedback.  Note that the mockup is not the final version.  It is used as a way to communicate ideas.
 +
[http://www.eclipse.org/cosmos/data_visualization/demo/mockups/i9/cmdfViewer.html graph viewer mockup]
 +
 
 +
[[Category:COSMOS_Bugzilla_Designs]]
 +
 
 +
==GraphResponseViewer Widgets Manual Testing==
 +
 
 +
The manual tests will cover running the 4 CMDBF Queries for the ExampleMDR, and the 2 CMDBF Queries for the SML MDR. These queries are available in the cosmos-demo directory cosmos-demo\cosmos-client\cmdbf-queries\.
 +
<br>
 +
# Start up the Management Domain and the two Data Managers (ExampleMDR and SML MDR)
 +
# Start the COSMOS UI
 +
# Wait for the Tree of available MDRs in the NAV Panel
 +
# Run the 4 Example MDR CMDBF Queries
 +
## Right-Click the MDR
 +
## Click Submit-Query
 +
## Fill in the CMDB-Query XML from the cosmos-demo directory
 +
## Click Submit
 +
## Check that the widgets have been loaded in the Details Pane
 +
### Check that the Combo Box is displayed, and check its contents
 +
### Check that the Nodes/Edges Grid widget is displayed, and shows populated rows
 +
### Check that the Records grid is shown and is empty
 +
## Change the combobox value to the next one displayed in the combobox
 +
### Check that the 1st grid reflects the change
 +
### Check that the second grid is emptied
 +
## Click on cell in the top grid
 +
### Make sure the Records Grid is changed to display the record ID and the Detail XML

Latest revision as of 12:44, 20 February 2008

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 0.2 Sheldon Lee-Loy
Code 2
Test 0.5
Documentation 0.5
Build and infrastructure 0.2
Code review, etc.*
TOTAL 3.4

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

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 pseudo schema of the CMDBf graph response. 

<queryResult>
   <nodes templateId="xs:ID">
      <item>
        <record>
        xs:any
           <recordMetadata>
              <recordId>...</recordId>
              <lastModified>...</lastModified> ?
              <baselineId>...</baselineId> ?
              <snapshotId>...</snapshotId> ?
              xs:any
           </recordMetadata>
        </record> *
         <instanceId>
            <mdrId>xs:anyURI</mdrId>
            <localId>xs:anyURI</localId>
         </instanceId> +
         <additionalRecordType namespace="xs:anyURI" localName="xs:NCName"/> *
      </item> +
    </nodes> *
    <edges templateId="xs:ID">
       <relationship>
          <source>
             <mdrId>xs:anyURI</mdrId>
             <localId>xs:anyURI</localId>
          </source>
          <target>
             <mdrId>xs:anyURI</mdrId>
             <localId>xs:anyURI</localId>
          </target>
          <record>
             xs:any
             <recordMetadata>
                <recordId>...</recordId>
                <lastModified>...</lastModified> ?
                <baselineId>...</baselineId> ?
                <snapshotId>...</snapshotId> ?
             </recordMetadata>
          </record> *
          <instanceId>
             <mdrId>xs:anyURI</mdrId>
             <localId>xs:anyURI</localId>
          </instanceId> +
          <additionalRecordType namespace="xs:anyURI" localName="xs:NCName"/> *
       </relationship> +
    </edges> *
</queryResult>

As stated in the CMDBf 1.0 specification document the graph response is made up of <nodes> and <edges> elements. Each of these elements have an associated 'templateId' attribute that corresponds to the 'templateId' attribute used to construct the CMDBf query.

Creating a tab layout will improve the visualization of the node and edge elements. A tab can be constructed for each node or element. The title of the tab will correspond to the templateId. This will logically separate the edge and node contents. Color coding or icons can be used to distinguish between a node or edge.

Each tab will contain a table that will show the contents of the node or edge.

View Table Mockup

Visualizing a node

The table view will show item and record information. Note that the node and edges are shown as the top level tabs. The following mockup follows the sample graph response outlined under the "4.3.2 GraphQuery Response" under the CMDBf 1.0 specification document. Note that the mockup uses a sketching tool used for SWT widgets. This tool was used to create mockups easily. The final widget should utilize dojo widgets. As a result buttons were used to represent the tab buttons.

214145ItemTab.jpg

The following user interactions are possible:

  • When the user selects a row in the item table the record table and additional record type table are populated. As a result the last tables show the associated records and additional record types.
  • The second table that lists the records contains expansion rows that the user can expand or collapse. When the row is expanded the content of the record is shown.

Visualizing a edge

The following mockup shows how an edge will be rendered in the view. The only difference between this view and the node view is outlined in red. The additional columns will provide information on the source and target mdrs of the relationship.

2141445RelTab.jpg

The following user interactions are possible:

  • When the user selects a row in the item table the record table and additional record type table are populated. As a result the last tables show the associated records and additional record types.
  • The second table that lists the records contains expansion rows that the user can expand or collapse. When the row is expanded the content of the record is shown.
  • The user can click on the source or target of the relationship. At this point the widget will jump to the item that represents the source or target.

Updated Mockups based on user feedback

New214145.jpg

New214145Filter.jpg

Widget Design

<TODO - update text to reflect new mockup/>

The CMDBf graph response widget is constructed from several simple widgets. The following shows the hierarchy of widgets:

  • Tab Widget - responsible for rendering the top level tabs
    • Item Widget - responsible for rendering the item table lists in the details view
    • Relationship Widget - responsible for rendering the relationship table lists in the details view
  • Record Widget - responsible for rendering the record table

For each of the above table a data feed is required to get the header information for the tabs and table. Additional data feeds are required to get the table row content.

Open Issues/Questions

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

Update Mockup

The following is a running mockup of the graph viewer based on feedback. Note that the mockup is not the final version. It is used as a way to communicate ideas. graph viewer mockup

GraphResponseViewer Widgets Manual Testing

The manual tests will cover running the 4 CMDBF Queries for the ExampleMDR, and the 2 CMDBF Queries for the SML MDR. These queries are available in the cosmos-demo directory cosmos-demo\cosmos-client\cmdbf-queries\.

  1. Start up the Management Domain and the two Data Managers (ExampleMDR and SML MDR)
  2. Start the COSMOS UI
  3. Wait for the Tree of available MDRs in the NAV Panel
  4. Run the 4 Example MDR CMDBF Queries
    1. Right-Click the MDR
    2. Click Submit-Query
    3. Fill in the CMDB-Query XML from the cosmos-demo directory
    4. Click Submit
    5. Check that the widgets have been loaded in the Details Pane
      1. Check that the Combo Box is displayed, and check its contents
      2. Check that the Nodes/Edges Grid widget is displayed, and shows populated rows
      3. Check that the Records grid is shown and is empty
    6. Change the combobox value to the next one displayed in the combobox
      1. Check that the 1st grid reflects the change
      2. Check that the second grid is emptied
    7. Click on cell in the top grid
      1. Make sure the Records Grid is changed to display the record ID and the Detail XML
Retrieved from "https://wiki.eclipse.org/index.php?title=COSMOS_Design_214145&oldid=83158"

This page was last modified 12:44, 20 February 2008 by Eclipsepedia anonymous user Unnamed Poltroon.

Back to the top