Bug 610155

Type: trait[alias

Suggest: trait[aliases]
Suggest: trait[jboss.web:type=Host,host=%name%:aliases]

Type: trait[aliases]=

Suggest: "[]"

Type Type: trait[aliases]="[]"

Results: <empty>

-----

So the "[]" value was suggested even though there are no results with "[]" as the value for the "aliases" trait.  In this case, the "[]" is only a valid suggestion for the <jboss.web:type=Host,host=%name%:aliases> trait.

Suggested enhancement is two-fold:

1) By default, provide substring matching for the bracketed parameter:

So "trait[aliases]"
Translates to "LOWER(schedule.definition.name) LIKE '%aliases%'"
Instead of "schedule.definition.name = 'aliases'"

But then we should also support the boundary matching (startsWith, endsWith, and exact) the same as we do for values on the right-hand side of the comparison operator.  So if the user wants to perform more precise matches, they could add additional boundary qualifiers:

trait[^aliases] --> "LOWER(schedule.definition.name) LIKE 'aliases%'"
trait[aliases$] --> "LOWER(schedule.definition.name) LIKE '%aliases'"
trait[^aliases$] --> "LOWER(schedule.definition.name) LIKE 'aliases'"

2) Do not provide suggestions which have no results.  In this case, if the user types "trait[^aliases$]", and if we know that there aren't any resources in the system with a value for that exact trait name, then it shouldn't be suggested in the first place.  However, this case will be MUCH more uncommon once #1 is implemented above, and all bracketed-parameter searches become relaxed.  Thus, I suggest we first tackle #1, and then revisit #2 only if the user interaction still feels awkward.