Red Hat Bugzilla – Bug 536006
DynaGroups Expression Builder
Last modified: 2014-11-09 17:49:55 EST
two initial ideas:
2) use a series of successive drop-down menus that auto-populate depending on your previous choice (for instance, you choose "resource" and it populates the next drop-down with "parent / grandParent / name / version / type / ...", then you can choose "type" and it populates a third drop-down with "plugin / name / category".
Both strategies follow the same basic premise - keep track of currently built sub-expression, and offer options that would continue building it up. Are there other options?
A proposed expression builder interface.
This was requested by numerous customers. Upping the priority since it is low hanging fruit with what Joseph started.
Implementation of DynaGroups Expression Builder. This is based on Joseph's expression library, but allows you to actually build up the expression in the popup and then write it back to the edit screen.
1) ordering - make the top-to-bottom ordering the drop-down more consistent with the top-to-bottom ordering of the expressions, as well as the left-to-right ordering of the expression tokens
1a) when "expression type" is "resource type", output "resource.type.plugin" in the builder box first (putting "resource.type.name" second); also, leave the "resource.type.name" empty/blank until the user selects one from the list
1b) put "resource" drop-down above "expression-type"
2) "comparison type" drop-down options "startsWith" and "endsWith" should be prepended with a period, so that the generated expression is properly dot-delimited to help the parser *not* make mistakes chopping it up for analysis
3) "resource" drop-down options "parent" and "grantParent" do not work, instead they both produce expressions like "resource.null = <value>"
3a) these options do not work at all and do not seem to change the generated expression at all when "trait", "plugin configuration", "resource configuration" potions are selected
4) "expression type" drop-down always makes the first expression "resource.type.name = Apache HTTP Server", it should either be null until one is selected or it should default to the first item in the "resource type" drop-down that gets generated after selecting the appropriate plugin
5) enablement / disablement options
5a) when "resource type" drop-down is an empty list, replace it with the printed message "there are no types defined by the selected plugin"
5b) when "property names" drop-down is an empty list, replace it with the printed message "there are no properties defined by the selected type"
5c) if "expression type" selected option is "resource type", suppress / disable "comparison type" and "value" elements
6) user intuitiveness - similar to, but more direct than enablement / disablement options
6a) maybe only populate the "defining plugin" / "resource type" drop-downs with elements that are known to have resource types that have properties - this would be a complete replacement for options 5a & 5b
1a, 1b, 2, 3, 3a, 5c,
4, 5a, 5b, 6a
Completed the first version of the DynaGroups wizard. (this has actually been completed and checked in for weeks, but we've decided to release it as that version without that those last few enhancements which have been moved into RHQ-787)
This just needs some basic UI testing. Test the various drop-down combinations for generating standard dyna-group queries. Some example queries to shoot for can be seen as the examples in the dyna-group documentation page.
I went through the subfeatures list and tried them all on the expression builder. Everything is working as-described. rev1385, linux, postgres.
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-401
Imported an attachment (id=368823)
This bug is related to RHQ-686
This bug is related to RHQ-810
This bug relates to RHQ-702