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"
| Line 56: | Line 56: | ||
=Design= | =Design= | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
The following are some design issues: | The following are some design issues: | ||
Revision as of 14:56, 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
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