text: COSMOS Design 214794
  From Eclipsepedia
  Back to Data Reporting Design
  Change History
  Workload Estimation
  '* - 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
  After further reviewing the mockup it was suggested that the user should have a better method of associating items and relationships. The following mockups adds additional tree widget that shows the association between items and relationships. The user would use the first tree to create the item or relationship template id. While the second section is used to populate the contents of the item or relationship element.
  The next mockup illustrates the change in the tree when the user adds a relationship. A relationship must always have a target and a source. One idea is to always add a default target node when a relationship node is created. This default node can indicate to the user that it is a place holder for the user to edit. Furthermore if a item is deleted from the root node and a relationship references the deleted item the target node is set to a place holder node. If a "New Element" is selected a top level node is added to the tree that represents the new element. If an existing node is selected a reference to the node is add to the relationship.
  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.
  Manual Test Cases
  The following are the steps to run the end to end manual tests
  1. Follow the instructions at
  2. Right click the "Example MDR" node in the Data Managers pane. A pop-up menu should show up with a menu item called "Create query"
  3. Select the "Create query" menu item.
  4. A Dialog box should be shown with three sections. The Dialog box should have a title and a description. The top level pane should show a tree with one node that has a value of 'query'
  5. Right click the node and select 'Add item'
  6. Another dialog box should appear to enter the item template id. Enter 'items' in the text box and click OK.
  7. The top tree should add an 'items' node under the 'query' node. In addition the bottom left pane should contain a tree with one node that is named 'itemTemplate'
  8. Right click the 'itemTemplate' node in the bottom left pane and select 'add contentSelector'
  9. The bottom right pane should present a table with the attributes of the contentSelector node. That is it should should matchRecords in the attribute columns and true in the Value column.
  10. Right click the itemTemplate node again and make sure that the 'add conentSelector' option is not shown in the menu. This option should only be shown if there are no contentSelector nodes udner the 'itemTemplate.
  11. Delete the contentSelector node by right clicking the 'contentSeletor' node and select the 'delete contentSelector'. The bottom left tree should now only have 1 root node named 'itemTemplate'. Also, the bottom left pane should be cleared and show a blank pane.
  12. Right click the itemTemplate node and select 'add RecordConstraint'. This should add a 'recordConstraint' node under the 'itemTemplate' node in the bottom left pane.
  13. Right click the recordConstraint node and select 'add recordType. This should add a 'recordType' node under the recordConstraintNode' node in the bottom left pane. The bottom right pane should show a table with namespace and localName.
  14. In the table click the table cell next to the localName cell and under the Value cell. This should allow you to edit the cell
  15. Type 'student' and press enter.
  16. Click on the 'Preview XML' button on the bottom of the page. This should show the following xml in the preview tooltip pane.
  <?xml version="1.0" encoding="UTF-8"?> <s:query xmlns: <s:itemTemplate <s:recordConstraint > <s:recordType </s:recordType> </s:recordConstraint> </s:itemTemplate> </s:query>
  17. Click on the 'Preview XML' button again to remove the tooltip pane.
  18. Click Submit.
  19. A "CBMDB Query" node showing the date the query was submited should be added to hte "Example MDR" node.
  20. Click on the "CMDBf Query" node. The "Details" pane should show a node tree
  21. Expand the tree in the "details" pane and verify that the tree structure is the expected graph query response. The tree should visualize the following xml structure. Note the tree structure shows the node structure of the xml. The properties view should show the attribute values of each node when selected.
  <?xml version="1.0" encoding="UTF-8"?><dyn:queryResponseType xmlns: <dyn:queryResponseType <nodes templateId="items"> <item> <record> <student> <identity firstName="Mike" id="03" lastName="Lee"/> </student> <recordMetadata> <recordId>03</recordId> </recordMetadata> </record> <instanceId> <mdrId>org.eclipse.cosmos.samples.cmdbf.XMLRepository</mdrId> <localId>03</localId> </instanceId> </item> <item> <record> <student> <identity firstName="Jane" id="02" lastName="Ryerson"/> </student> <recordMetadata> <recordId>02</recordId> </recordMetadata> </record> <instanceId> <mdrId>org.eclipse.cosmos.samples.cmdbf.XMLRepository</mdrId> <localId>02</localId> </instanceId> </item> <item> <record> <student> <identity firstName="Bob" id="01" lastName="Davidson"/> </student> <recordMetadata> <recordId>01</recordId> </recordMetadata> </record> <instanceId> <mdrId>org.eclipse.cosmos.samples.cmdbf.XMLRepository</mdrId> <localId>01</localId> </instanceId> </item> </nodes> </dyn:queryResponseType> </dyn:queryResponseType>
  Results
  1. There should not be any exception that is thrown when expanding the nodes.
  Additional Manual tests are defined as TPTP Manual tests. The following is the CVS information where the tests are stored.
  Repository: /cvsroot/technology
  CVS Location: org.eclipse.cosmos/tests/common/org.eclipse.cosmos.examples.e2e.tests/manual/DataVisualization.UI.Component.Widget.testsuite