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"
(→Design) |
|||
| Line 56: | Line 56: | ||
=Design= | =Design= | ||
| − | + | There are two types of customization that is possible: | |
| − | + | *application driven | |
| − | + | *data driven customization | |
| − | + | ||
| − | + | ||
| − | + | ||
===Application-Driven Customization=== | ===Application-Driven Customization=== | ||
| Line 69: | Line 66: | ||
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. | 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. | + | 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. |
| + | |||
| + | Application-Driven Customization is already provided by the COSMOS UI framework | ||
===Data-Driven Customization=== | ===Data-Driven Customization=== | ||
| − | + | 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 structure. An additional step is needed to normalize the graph response to the JSON data structure that the tree expects. | |
In this case, a registry service is need to associate a view with a graph response instead of a graph query | 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 15:02, 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
There are two types of customization that is possible:
- application driven
- data 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.
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.
Application-Driven Customization is already provided by the COSMOS UI framework
Data-Driven Customization
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 structure. An additional step is needed to normalize the graph response to the JSON data structure that the tree expects.
In this case, a registry service is need to associate a view with a graph response instead of a graph query