Community
Participate
Working Groups
I20100802-1800. I tried to search a certain set of options (by name) along with a given value but failed. We should support name~value patterns, e.g. "param~warn"
M1 if easy to fix. M2 otherwise.
I would rather expect "param ~warn" or "~warn param" to do this.
>I would rather expect "param ~warn" or "~warn param" to do this. If so, you also need to allow "param " to match "param". Currently this results in 0 matches (if there is no "param " in the UI). That we then add matches back after typing ~warn would be strange.
(In reply to comment #3) > >I would rather expect "param ~warn" or "~warn param" to do this. > If so, you also need to allow "param " to match "param". Currently this results > in 0 matches (if there is no "param " in the UI). That we then add matches back > after typing ~warn would be strange. The discussion is whether there is space in between or not, right? I don't see how that matters (though aesthetically speaking, I prefer having space). The result would be an && of both conditions, for this example the result would be all options with labels matching 'param' AND with value matching 'warn'. I don't see how the matches are added back. (In reply to comment #2) > I would rather expect "param ~warn" or "~warn param" to do this. Markus, are you sure you want to have the second option as well. Someone will then try 'method ~warn param'. Does the result return options with labels matching 'method' OR 'param' AND value matching 'warn? Or what happens if we have a value with a space in it? (though right now we do not have this case) To keep it simple I would support only 'name ~value'.
>The discussion is whether there is space in between or not, right? I don't see >how that matters Well, currently spaces do matter, e.g. enter "block" then add a space ==> boom no matches. It would be strange to me if matches come back magically if I enter "~warn" afterwards. So, if we go for 'name ~value', then we must first agree that any spaces after the name are ignored i.e. "block " or "block " would give the same result as just entering "block". If we do so, I think we can keep it simple and only allow name<trailing whitespace is ignored> ~value<trailing whitespace is ignored> name<at least one whitespace>~value
(In reply to comment #5) > >The discussion is whether there is space in between or not, right? I don't see > >how that matters > Well, currently spaces do matter, e.g. enter "block" then add a space > ==> boom no matches. It would be strange to me if matches come back magically > if I enter "~warn" afterwards. So, if we go for 'name ~value', then we must > first agree that any spaces after the name are ignored i.e. "block " or "block > " would give the same result as just entering "block". If we do so, I think we > can keep it simple and only allow > name<trailing whitespace is ignored> > ~value<trailing whitespace is ignored> > name<at least one whitespace>~value yeah,I see the problem now... Will ignore trailing whitespace and support these 3 cases, and will try to get this done for M1.
Since we don't describe this syntax on the page, I think it should work both ways (<valueFilter><pattern> and <pattern><valueFilter>, stripping whitespace): - trim pattern - if <valueFilter> at beginning or end, remove it from pattern and trim remaining pattern again
Is also fine for me.
Created attachment 175815 [details] fix Fixed in HEAD.
.
Verified in I20100804-1800. Works well. Filed bug 321818 for a scenario that I missed.
