Skip to main content

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.

Jump to: navigation, search

Talk:COSMOS Design 214143

Revision as of 18:23, 8 January 2008 by Sleeloy.ca.ibm.com (Talk | contribs) (Ali's Questions/Comments)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Ali's Questions/Comments

  1. Adopters should be able to register selection/expansion listeners on MDR items that appear in the left panel. The solution that you propose in the enhancement should be an expansion listener instance that adopters can choose to use. In summary adopters will be able to:
    1. Indicate if an MDR is “expandable”.
    2. When the user expands an MDR in the left panel, one or more expansion listener is invoked
    3. Adopters can choose to use an instance of an expansion listener that uses your meta-data and query configuration to determine the children of the MDR.

(Sheldon Comment) This is already possible with the current framework. Users would configure the navigation widget to 'register' an expansion query to a particular node'

  1. You also need to consider cases where a data manger is not an MDR, in which case the query language can be something different than an XML file. I suggest requiring the query file to be an ASCII-readable file instead of an XML file.

(Sheldon Comment) Yes I agree. The design could provide extension points to disable the template processor, cmdbf query procesor and formatter. A extension point could be added to add different processors within the chain. Hmm... maybe I shouldn't distinguish between processors. I should just have a processor queue that formats the data and passes the information to the next processor in the queue. I think this is a more generic solution. This type of processing is related to the design for ER 214153

  1. The nesting of the queries isn’t intuitive. I believe you use the classNode key in the meta-data but the description of the key is a little vague in your design document

(Sheldon comment) I will explain this in more detail in the design document

  1. Shouldn’t the meta-data include a query processor that can understand the query result that is returned?

(Sheldon comment) I don't want to have a tight coupling between the query result visualization and query. I want to have a loose coupling for better flexibility and reuse of the queries. Furthermore, I may have a single visualization that may use multiple queries.

Back to the top