Bugzilla – Full Text Bug Listing
| Summary: | [api] New: Allow file name search in Remote Search to not be case sensitive | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] Target Management | Reporter: | Samuel Wu <samuelwu> | ||||||||
| Component: | RSE | Assignee: | David McKnight <dmcknigh> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | Martin Oberhuber <mober.at+eclipse> | ||||||||
| Severity: | enhancement | ||||||||||
| Priority: | P3 | CC: | mkomor | ||||||||
| Version: | 3.0.1 | Keywords: | api | ||||||||
| Target Milestone: | 3.1 M7 | Flags: | mober.at+eclipse:
pmc_approved+
|
||||||||
| Hardware: | PC | ||||||||||
| OS: | Windows XP | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Samuel Wu
This would require an API change in SystemSearchString (i.e. to include an isFileNamesCaseSensitive boolean). It's too late for API changes in RSE 3.1. We currently have ISubSystemConfiguration.isCaseSensitive() to switch case sensitivity on a global level. Would that be sufficient here, or is the request really to search case insensitive on a file system / subsystem that's actually marked as case sensitive? Note that when we globally switch to case insensitive, client will e.g. get back FOO, Foo, FoO and can perform second-level filtering on those results (without API change) if it really wants them case sensitive. (In reply to comment #2) > We currently have ISubSystemConfiguration.isCaseSensitive() to switch case > sensitivity on a global level. Would that be sufficient here, or is the request > really to search case insensitive on a file system / subsystem that's actually > marked as case sensitive? > > Note that when we globally switch to case insensitive, client will e.g. get > back > FOO, Foo, FoO > and can perform second-level filtering on those results (without API change) if > it really wants them case sensitive. > I think the request is to have an option (i.e. a checkbox in the search page) to search case-insensitive on a case-sensitive file system. So if a file system contains FOO, Foo, and FoO, the user has the choice of searching for "Foo" (1) via a case-sensitive search, resulting in "Foo" or (2) via a case-insensitive search, resulting in "FOO", "Foo" and "FoO" Created attachment 129742 [details]
api changes required
I think this would be the only API change.
API change looks good to me, I'm fine with this for M7. I'm a bit surprised why you want the isFileNamesCaseSensitive field to be protected rather than private, but the others are protected too so that's OK for me. BTW, a workaround without any change might be to use a REGEX thats case insensitive, i.e. convert any case insensitive search into a REGEX using Java's specifier for matching case insensitive. If the user specifies the proper case insensitive regex in the UI, this should work in RSE today. Created attachment 129756 [details]
patch with support for controlling file name search case sensitivity
I've committed the patch to cvs. I notice that the default (and old RSE 3.0 behavior) is to perform searches case sensitive == true.
But in SystemSearchPage, DialogSettings are stored and a new slot ("isCaseSensitive") is used in those DialogSettings. If I run RSE 3.1 on and old RSE 3.0 workspace, then the DialogSettings won't have the new slot, so it falls back on its default value (isCaseSensitive = false).
This is different than the expected RSE 3.0 behavior of isCaseSensitive = true.
This may not be an issue since searching case insensitive is generally preferred over searching case senstivie since more matches are returned. Anyways, I'd like you to think again whether this is indeed what you want.
Created attachment 132472 [details]
patch using true as the default
To preserver the default 3.0 behaviour this patch should assume case-sensitive when no value is set. Martin, is this what you had in mind?
Yes, this patch looks good. Thanks! Okay, I've committed the change to cvs. |