Community
Participate
Working Groups
Unresolved issues from bug 175524: I skimmed over FilteredItemsSelectionDialog 1.20 and these API problems jumped into my eyes: - Field contentProvider is protected but undocumented. Why is it not private? - createFilter() says: "Can be <code>null</code>, * no filtering will be applied then, causing no item to be shown in * the list." => That wouldn't make much sense, a dialog without any items. If the implementation really supports null, then I guess it should mean that all items are shown. - SelectionHistory's Javadoc says: "The list is bounded at size <code>MAX_HISTORY_SIZE</code>". API Javadoc should not refer to private constants. If you don't want to add API to change the size, the Javadoc should just say "The list is bounded at a certain size". - There are two methods ItemsFilter#matchesRawNamePattern(..). The variant with the String parameter is never called (and should probably be removed). The javadoc of the remaining variant should tell when it is called and what it is used for. - Javadoc: unnecessary <p> tags in ItemsFilter#equalsFilter and ItemsFilter#isSubFilter
Created attachment 60803 [details] Patch respond for Markus usggestions I resolved all Markus issues without proposition of change searching implementation. Now we don't start searching if filter is null. I will try change it in the next patch.
API REQUEST In FilteredItemsSelectionDialog. Remove the overloaded method ItemsFilter#matchesRawNamePattern(String) and make the ContentProvider for the dialog private. ItemsFilter#matchesRawNamePattern(Object) is the only one called in the implementation and the overloaded version is superfluous. The internal ContentProvider should never have been protected as it is only meant to be accessed by FilteredItemsSelectionDialog. RISKS None. No one is currently calling these methods.
+1
Fix has been released on 2007-03-14 and is in M6.
