Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "COSMOS Design 214158"
(New page: Back to Data Reporting Design = '''Change History''' = {|{{BMTableStyle}} !align="left"|Name: !align="left"|Date: !align="left"|Revised Sections: |- |Sheldo...) |
|||
Line 71: | Line 71: | ||
Consider we have a library of widgets that are able to visualize certain asset information. These widgets expect a specific data model. For example, I may have a table widget that show a list of applications installed on a particular machine. This table widget expects a specific JSON data structure to visualize the list of application. Now consider a MDR that contains that application and machine information. A query would be sent to this MDR to get that specific information and a CMDBf graph response would be returned. The graph response would embed the information in a <record> element. At this point when the graph response is recieved by the client. The client can not render the graph response as a table since it does not understand the graph response. An additional step is needed to normalize the graph response to the JSON data structure that the tree expects. | Consider we have a library of widgets that are able to visualize certain asset information. These widgets expect a specific data model. For example, I may have a table widget that show a list of applications installed on a particular machine. This table widget expects a specific JSON data structure to visualize the list of application. Now consider a MDR that contains that application and machine information. A query would be sent to this MDR to get that specific information and a CMDBf graph response would be returned. The graph response would embed the information in a <record> element. At this point when the graph response is recieved by the client. The client can not render the graph response as a table since it does not understand the graph response. An additional step is needed to normalize the graph response to the JSON data structure that the tree expects. | ||
− | Application-Driven Customization | + | ===Application-Driven Customization=== |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | Tradionally, the application developer determines the view that will render the data. For example, if a cmdbf query is constructured to return statistical data for a particular web server the application developer may decide to render the statistical data as a line chart. In other cases, the application developer may want to render the data as a table depending on the application context. | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | In this case, a registry service is need to associate a view with a graph query instead of the graph response. Note that the view expects a certain graph response format that is dictated by the graph query. | |
− | + | ||
− | + | ||
− | + | ||
− | view | + | |
− | + | The above mechanism requires a datafeed that accepts a graph query id and returns a graph response that tags the response with the graph query id. The graph query id will be used to lookup the registered view assoicated with the graph query. | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | In this case, a registry service is need to associate a view with a graph | + | ===Data-Driven Customization=== |
− | response instead of a graph query | + | In this case the data recieved from a CMDBf graph response will determine the view to render the graph response. Does data driven customization useful? Need to understand uses cases that would make this useful. |
+ | |||
+ | In this case, a registry service is need to associate a view with a graph response instead of a graph query | ||
[[Category:COSMOS_Bugzilla_Designs]] | [[Category:COSMOS_Bugzilla_Designs]] |
Revision as of 14:55, 8 January 2008
Back to Data Reporting Design
Contents
Change History
Name: | Date: | Revised Sections: |
---|---|---|
Sheldon Lee-Loy | 01/08/2008 |
|
Workload Estimation
Process | Sizing | Names of people doing the work |
---|---|---|
Design | 0.2 | Sheldon Lee-Loy |
Code | ||
Test | ||
Documentation | ||
Build and infrastructure | ||
Code review, etc.* | ||
TOTAL |
'* - includes other committer work (e.g. check-in, contribution tracking)
Requirement
A programming strategy is needed to associate a customized view with a particular graph response. A graph response is a generic structure that represents data from a data manager. Customized data is wrapped inside a graph response that an application may want to provide customized view to visualize the data.
Design
Lets consider some different types of customized views.
- Creating graph data. The graph can be a pie chart, line chart, bar chart, etc. Determine which
chart type to use can be business-user specific not data driven.
- Show the data in the tree
- Show the data in a table
- Complex widget that is composed of many simple widgets
The following are some design issues:
- A graph response is a complex structure. How can a customized view be associated with a graph response or a fragment of a graph response?
- Should the ui customization be data driven or application driven.
Consider we have a library of widgets that are able to visualize certain asset information. These widgets expect a specific data model. For example, I may have a table widget that show a list of applications installed on a particular machine. This table widget expects a specific JSON data structure to visualize the list of application. Now consider a MDR that contains that application and machine information. A query would be sent to this MDR to get that specific information and a CMDBf graph response would be returned. The graph response would embed the information in a <record> element. At this point when the graph response is recieved by the client. The client can not render the graph response as a table since it does not understand the graph response. An additional step is needed to normalize the graph response to the JSON data structure that the tree expects.
Application-Driven Customization
Tradionally, the application developer determines the view that will render the data. For example, if a cmdbf query is constructured to return statistical data for a particular web server the application developer may decide to render the statistical data as a line chart. In other cases, the application developer may want to render the data as a table depending on the application context.
In this case, a registry service is need to associate a view with a graph query instead of the graph response. Note that the view expects a certain graph response format that is dictated by the graph query.
The above mechanism requires a datafeed that accepts a graph query id and returns a graph response that tags the response with the graph query id. The graph query id will be used to lookup the registered view assoicated with the graph query.
Data-Driven Customization
In this case the data recieved from a CMDBf graph response will determine the view to render the graph response. Does data driven customization useful? Need to understand uses cases that would make this useful.
In this case, a registry service is need to associate a view with a graph response instead of a graph query