Difference between revisions of "COSMOS Design 223270"
|Line 10:||Line 10:|
Revision as of 06:41, 8 May 2008
Back to Data Reporting Design
|Process||Sizing||Names of people doing the work|
|Build and infrastructure|
|Code review, etc.*|
'* - includes other committer work (e.g. check-in, contribution tracking)
The COSMOS UI provides a way to create queries to an MDR. However it does not provide a mechanism to manage these queries. Some of the management services are as follows:
- Ability to persist newly created queries
- Ability to rename queries
- Ability to delete existing queries
- Right-Click on the query, show a menu that has the option to run/execute
- Left-Click on the Query, shows the cached query
- When an execute option is chosen, the query request and the query results should be persisted. The user should not have to make a decision as to whether to persist or not, it should just happen.
- Persist the files on the client machine in XML files. If the current mechanism is storing the requests and results in the dom, then the act of doing an execute will still update the dom, but will also create the XML files.
- If saving on the Client side, where will the files go? How do you decide where? Do you decide within the UI, or outside of the UI? If you decide in the UI, how will that be implemented?
- We should not just save the last result set. Multiple query results should be displayed within the Query Node.
- The query node in the tree should have one or more optional child nodes for the query responses.
- To create a query node, you need to right-click on the MDR and select the Query Builder option. Then create the query in the query builder.
- Left-click on a query node to show the query result in the details view (Using the XML Outputter)
- Right-click on a query node and choose "execute" (or "delete").
- Left-Click on the query Result to show in the details view (Using the GraphResponseViewer)
- Right-Click on a query result and choose "delete" (or "register/deregister" configuration items").
- If we are persisting requests and results as XML files, they could be stored in <tomcat>\webapps\COSMOSUI\queries directory, which can be configured in the web.xml.
- Storing on the server means that you can pick the requests/queries up from anywhere.
- One thing to bare in mind is that, if the main reason for having this mechanism is to be able to easily create queries, store them, delete them and share them, then the developer probably has their own server running. I don't see the maintenance of the persisted files would be something that you do in production.
- There needs to be a mechanism that allows someone to put their xml files in a specific place that web.xml points to so that when the UI starts up, it checks that area and populates the UI nodes. In effect you could say that if this mechanism does exist, that deleting a node or deleting a request or response could be done by removing the xml file.
- So requests and responses as xml files are maintainable, but the structure of the nodes also needs to be persisted. So if for example you had a node called "All Students" then create a directory called "All students", and the xml files would go into that directory. Just to reiterate, you could as a first phase use the directory structure, with xml files in them, as a manual way of maintaining things, then add the menu options as a second phase.
Consider the current architecture that outlines how the client browsers interact with the COSMOS UI to show queries in the navigator. A set of predefined queries are stored in a repository. This repository is read and loaded when the client browser starts up.
There are two methods to support user defined queries. Traditionally, user data is stored on the server side. However there are several services that are required to manage user data on the server side. Consider the following architecture change.
Notice that the server now needs a mechanism to manage user data (ie. user profiles, user login services, etc.)
The second method does not make use of the server to store user data. Rather the client browser stores the user data using the "DOM storage" feature provide in HTML 5 spec. (Refer to http://www.w3.org/TR/html5/#storage).
Consider the following diagram.
Dom storage is currently only available inf FireFox 2. In other cases the Google Gadget or Flash storage plugin is required in the browser.