Difference between revisions of "Talk:COSMOS Design 214145"

Revision as of 17:17, 30 January 2008

Back to Design 214145

• The tabular view shouldn’t be the default view for all MDRs. Adopters may prefer to associate customized visualization as a default view. Give adopters the option of making this view default but don’t make it a hard requirement.

(Sheldon's comment) Yes it is currently possible to configure specific MDRs to have customized views

• Here are some hooks that adopters will need:

1. Selection listeners on any item selected
2. Double click listeners on any item displayed
3. Expansion listeners for any expandable item
4. Addition of context menus to items

(Sheldon's comment) Yes I agree. The adopters would extend the dojo javascript widget to add these listeners. Much like Swing or SWT widgets. After they can configure the COSMOS UI to use their new customized widget instead of the CMDBf table response viewer

• Nested tabs and tables make your views look convoluted. Here are some suggestions:

1. Get rid of the simple and detail nested tab
2. Instead of the detail tab, display the information using two tables. See an example of an item template below. In the case where a tab corresponds to a relationship template, relationships are displayed in the upper table. The lower table displays all associated records of selected item(s) or relationship(s):
   
   

(Sheldon's comment) This layout seems more useable

• A user should be able to navigate from a relationship entry to either the source or target item (e.g. using a context menu – Show Source Item)

(Sheldon's comment) I'm concerned that the user may lose their initial context when jumping to the source and target since there's is no back link from the source or target to the relationship. I am wondering if there's a better way to show this linkage. One thought might be showing the item information in a tooltip dialog. An example of this can be seen in the following page: http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/test_Dialog.html

• A useful action in this tabular view can be the ability to retrieve the source MDRs that an item/relationship originates from. A context menu action (e.g. "Show Source Repositories") on an item/relationship can for example highlight source MDRs in the Data Manager view.

(Start Martin's Comments) --Marty 09:25, 29 January 2008 (EST)
(Sheldon's Reply in bold)--Sheldon 03:45, 29 January 2008 (EST)
I have been through the design, and I have some comments/questions to share with you all. (This is mainly my thoughts as I went through it, I am not expecting immediate answers to anything, I am just documenting what I believe we have to find out to do this ER)

1. Its going to be used as a default view. Yes this is going to be the default view
   1. What is the current view being used in the i8 e2e ? Tree viewer and Property Viewer - the tree view shows the structure of the XML and the property view shows the attribures on the element
   2. What is the current Outputter and where is the code?All the generic outtputters are under the org.eclipse.cosmos.dr.drs.service.handler package. org.eclipse.cosmos.internal.dr.drs.service.outputter.XMLTreeOutputter is the outputer that produces the JSON that represents the JSON structure
   3. What name will we give the new generic Outputter?There is no formal naming convention for outputters. Maybe call it CMDBfGraphResponseOutputter
2. What does extension point really mean in this design doc?
   1. Is it a similar concept to Eclipse Plugin Extension points? I sort of overloaded this notion and applied it to the UI. It is meant to be a mechanism for deployers to replace the default widget representation with their own representation.
   2. Am I right in assuming that we have not defined what the extension points are? Yes we haven't defined what extension points are.
   3. What about an example of an extension point?he menu bar in the navigation tree provides a way for users to contribute their own menu item. There's a notion of a widget registry that holds a map. The map is keyed on a tag name. The value of the map is the widget configuration. In the /org.eclipse.cosmos.dr.ps.components/WebContent/js/org/eclipse/cosmos/provisional/dr/ps/components/utility/common.js javascript file You can use the org.eclipse.cosmos.provisional.dr.ps.components.utility.UIContext.createWidgetView method to create a widget based on a tag name. You can look at org.eclipse.cosmos.provisional.dr.ps.components.widget.WidgetContainer.js to see how it is used. Each widget that is created will have a context object that is of type org.eclipse.cosmos.provisional.dr.ps.components.utility.UIContext. This class provides helper functions to create objects and widgets. It also provides methods to submit requests to outputters.
   4. Are we talking about extension points as to how the generic view can look, or are we talking about how we could extend the filtering system from the graph response to the widget?we are talking about allowing users to contribute their own visualization of the graph response. For example exploiters may want the ability to visualize the content of the record.
3. The toolbar
   1. Lets assume it is a part of this ER that we do near the end I was thinking of a tool bar that would provide buttons to filter and search for a particular record.
   2. What filtering will we do? On what fields? Do we have positive filtering as well as negative filtering? (eg, we may say ‘select everything where a = b’ or we may say ‘select everything where A not= B, or we may say ‘select everything where A > B’Yes I was thinking of supporting the basic filtering such as less than, equal, equal to, contains, like, not equal to etc.
4. Pseudo Schema
   1. This sounds to me as though it could be described as the bare minimum xml you would expect to see in a graph response.This is not an xml this the schema which was taking from the CMDBf 1.0 specification Section 4.3.2
5. templateID
   1. In 1 <queryresult> would it be so that
      1. the templateId for the node and the edge are always the same?The templateId is of type xs:ID. Therefore it should be unique. within the document.
      2. The templateId for the node and edge can be differentThe id has to be unique
6. Nodes and edges
   1. You can have multiple occurrences of each tag in 1 queryResult? (I think the CMDBF query is saying that)Yes you can
7. Tab Layout
   1. Where do I find an example that I can play with to see how this works ?You can get the mockup files from CVS. repository:/cvsroot/org.eclipse module:www/cosmos/data_visualization/demo. You can also look at the dojo examples files that are part of the dojo 1.0.2 release (http://download.dojotoolkit.org/release-1.0.2/dojo-release-1.0.2.zip). Look at dojo-release-1.0.2\dijit\tests\layout\test_TabContainer.html
   2. Is there any limitation as to the number of tabs (ie the number of templateIds) ? no there's no limit.
      1. If there is, how will this be implemented/configured ?
      2. If there are too many templateids, what do we say to the user ?The tabs will be stacked and always visible to the user. However after a certain limit the view will be unusable.
8. We can only display X, do you wnat to proceed? Yes we can prompt the user with a message. Maybe 20 could be the limit. This # should be based on some trail runs.
9. Sorry we cant display the templateids there are too many
10. Colour Coding or icons (Note the British way to spell Colour  )
    1. So will we use colour coding or icons? I think at most we should colour code the tabs to indicate whether the tab is an edge or a node. For the most part we should ignore using color or icons in this iteration. We can improve on the useability by adding color and icons in the next iteration.
    2. Which one?
    3. If Colour coding, what colours for each?I can find out from our useability person if he has any recommendation what colours we should use to represent a node or edge tab.
    4. If icons, what icons will we use?
11. . View table Mockup
    1. Of computer/user/order, which is a node, and which is an edge? I am assuming that the computer is a node, and the user and order are edges Maybe a better example to see would be to look at the cmdbf specification section 4.2. The example shows a query to get a list of users using a list of computers. In this example, the users and computers are nodes and the usage time is the relationship.
    2. Does the widget automatically change the tab colour when it has focus? Does that have to be programmed ? Is that what we want? The widget does not change color. The tab color should be determined when the widget initializes
    3. Population of the second table
       1. When the item is selected, are we populating the table by reading the total output from the outputter, or are we looking at a subset of that each tome? The point I am getting at is this.... We are not going to see what is in the records until a selection is made by the user, so at the point you have to figure out where all the records are, are we always looking at the outputter from the graph response, or are we in memory selecting everything related to the templateId, and searching just through that ? Then maybe we only go back to the original oututter output, when we go backwards (go back to selecting another templateID) ??

My initial preference is to get the entire graph response since this will make the outputter simpler and more inline with restful services. (ie. no need for session data). In this scenario the dojo widget will consume the json representation of the graph response and store it using a dojo datastore object. (http://dojotoolkit.org/book/dojo-book-0-9/part-3-programmatic-dijit-and-dojo/data-retrieval-dojo-data-0), Dojo data store object is the data access level for dojo widgets. The json structure should be structured in a way that it makes it easier for the widget to consume. For example you might have a top level json object that represents the tab names then each top level object would reference a table data store that represents what should be shown in each tab view. Note that this approach does not really scale since the graph response may be huge. This is a limitation of the cmdb queries since I can't ask the MDR for incremental graph response. We need to revisit this issue in future iterations.

1. 1. Are there any limitations on the number of additionalRecordTypes ?You can have 0 or more addtionalRecordTypes
2. Widget Design
   1. Tab Widget
      1. I want to see an example of the code to do this and play with it
   2. Item Widget
      1. I want to see an example of the code to do this and play with it
3. RealationShip Widget
   1. I want to see an example of the code to do this and play with it
   2. Record Widget
      1. I want to see an example of the code to do this and play with it
   3. The fact that we see these widgets in the design doc, leads me to think that they are dojo widgets that Sheldon has created, so could we have the code that you used to generate these ? You can get the mockup files from CVS. repository:/cvsroot/org.eclipse module:www/cosmos/data_visualization/demo. You can also look at the dojo examples files that are part of the dojo 1.0.2 release (http://download.dojotoolkit.org/release-1.0.2/dojo-release-1.0.2.zip). Look at the test folders for samples. You should also look at the dojo documentation for helpful information. http://dojotoolkit.org/book/dojo-book-1-0
   4. What do you mean by data feed?
      1. Data from an Outputter?
      2. You imply there is more than one data feed, so does that mean there is more than one output from our outputter?
      3. Please give me an example of what these two data feeds look like

Here is a sample json that you may want to produce:

[
{title:'user', nodeClass:'item' object:'221123', 
	store:{items:[
			{mdr:'http://localhid', localId:'1', 
				record:[
					{recordId:'8234324DFWER', lastModified:'11/2/2008', baseLineId:'URE928-34235', snapShotId'2873423ER'], content:'<custom>mycontent</custom>'},
					{recordId:'8214324DER', lastModified:'11/2/2008', baseLineId:'URE928-34235', snapShotId'2873423ER'], content:'<custom>mycontent</custom>'},
					{recordId:'8224324DWER', lastModified:'11/2/2008', baseLineId:'URE928-34235', snapShotId'2873423ER'], content:'<custom>mycontent</custom>'},
					{recordId:'8234324WER', lastModified:'11/2/2008', baseLineId:'URE928-34235', snapShotId'2873423ER'], content:'<custom>mycontent</custom>'}
				]
			},
			{mdr:'http://localhid2', localId:'2', 
				record:[
					{recordId:'8234324DFWER', lastModified:'11/2/2008', baseLineId:'URE928-34235', snapShotId'2873423ER'], content:'<custom>mycontent</custom>'},
					{recordId:'8214324DER', lastModified:'11/2/2008', baseLineId:'URE928-34235', snapShotId'2873423ER'], content:'<custom>mycontent</custom>'},
					{recordId:'8224324DWER', lastModified:'11/2/2008', baseLineId:'URE928-34235', snapShotId'2873423ER'], content:'<custom>mycontent</custom>'},
					{recordId:'8234324WER', lastModified:'11/2/2008', baseLineId:'URE928-34235', snapShotId'2873423ER'], content:'<custom>mycontent</custom>'}
				]
			},
			{mdr:'http://localhid3', localId:'3', 
				record:[
					{recordId:'8234324DFWER', lastModified:'11/2/2008', baseLineId:'URE928-34235', snapShotId'2873423ER'], content:'<custom>mycontent</custom>'},
					{recordId:'8214324DER', lastModified:'11/2/2008', baseLineId:'URE928-34235', snapShotId'2873423ER'], content:'<custom>mycontent</custom>'},
					{recordId:'8224324DWER', lastModified:'11/2/2008', baseLineId:'URE928-34235', snapShotId'2873423ER'], content:'<custom>mycontent</custom>'},
					{recordId:'8234324WER', lastModified:'11/2/2008', baseLineId:'URE928-34235', snapShotId'2873423ER'], content:'<custom>mycontent</custom>'}
				]
			},
			]
		      }
},
{title:'order', nodeClass:'relationship' object:'221123', 
	store:{items:[
			{mdr:'http://localhid', localId:'1', source:{mdrId:'http:/mymdr', localId:'source'},target:{mdrId:'http:/mymdr', localId:'target'},
				record:[
					{recordId:'8234324DFWER', lastModified:'11/2/2008', baseLineId:'URE928-34235', snapShotId'2873423ER'], content:'<custom>mycontent</custom>'},
					{recordId:'8214324DER', lastModified:'11/2/2008', baseLineId:'URE928-34235', snapShotId'2873423ER'], content:'<custom>mycontent</custom>'},
					{recordId:'8224324DWER', lastModified:'11/2/2008', baseLineId:'URE928-34235', snapShotId'2873423ER'], content:'<custom>mycontent</custom>'},
					{recordId:'8234324WER', lastModified:'11/2/2008', baseLineId:'URE928-34235', snapShotId'2873423ER'], content:'<custom>mycontent</custom>'}
				]
			},
			{mdr:'http://localhid2', localId:'2', source:{mdrId:'http:/mymdr', localId:'source'},target:{mdrId:'http:/mymdr', localId:'target'},
				record:[
					{recordId:'8234324DFWER', lastModified:'11/2/2008', baseLineId:'URE928-34235', snapShotId'2873423ER'], content:'<custom>mycontent</custom>'},
					{recordId:'8214324DER', lastModified:'11/2/2008', baseLineId:'URE928-34235', snapShotId'2873423ER'], content:'<custom>mycontent</custom>'},
					{recordId:'8224324DWER', lastModified:'11/2/2008', baseLineId:'URE928-34235', snapShotId'2873423ER'], content:'<custom>mycontent</custom>'},
					{recordId:'8234324WER', lastModified:'11/2/2008', baseLineId:'URE928-34235', snapShotId'2873423ER'], content:'<custom>mycontent</custom>'}
				]
			},
			{mdr:'http://localhid3', localId:'3', source:{mdrId:'http:/mymdr', localId:'source'},target:{mdrId:'http:/mymdr', localId:'target'},
				record:[
					{recordId:'8234324DFWER', lastModified:'11/2/2008', baseLineId:'URE928-34235', snapShotId'2873423ER'], content:'<custom>mycontent</custom>'},
					{recordId:'8214324DER', lastModified:'11/2/2008', baseLineId:'URE928-34235', snapShotId'2873423ER'], content:'<custom>mycontent</custom>'},
					{recordId:'8224324DWER', lastModified:'11/2/2008', baseLineId:'URE928-34235', snapShotId'2873423ER'], content:'<custom>mycontent</custom>'},
					{recordId:'8234324WER', lastModified:'11/2/2008', baseLineId:'URE928-34235', snapShotId'2873423ER'], content:'<custom>mycontent</custom>'}
				]
			},
			]
		      }
}
]

(End Martin's Comments) --Marty 09:25, 29 January 2008 (EST)

Bill's comments

I'm wondering if using the tabs with multiple tables with expansions to show the items and records of the query result may be confusing. How about using subrows in the DOJO grid widget? Refer to Dijit Grid Example for a picture of the grid. Each row would show an item or relationship (with an icon in the image view to show the type). The subrows of a relationship would show the source item, target item and any records. The subrows of an item would show its records.