Project: JDT
Bug 38062 [api] Provide API that allows to use text search for a new search (page)
Reported: 2003-05-23 14:57:56 | Status: resolved fixed

Use case: I wanted to take the basic TextSearch and change the LabelProvider in TextSearchResultCollector.aboutToStart(), since the one used there, FileLabelProvider(FileLabelProvider.SHOW_LABEL_PATH), displays filenames and java-related icons, while we wanted to display text and icons based on our Model. The LabelProvider I wanted to use is < 60 loc (incl. javadocs). In order to create a SearchPage, one must: (1) do some things with plugin.xml (no problem); (2) write a class that extends DialogPage and implements ISearchPage ... I thought it would be simple to copy the existing org.eclipse.search.internal.ui.text.TextSearchPage class, and simply replace the LabelProvider -- but in fact the LabelProvider is only created down in TextSearchResultCollector, so I would have to copy that too: Problem: TextSearchPage has the following dependencies, in packages org.eclipse.search.internal.{core, ui}.text, that are *not* public: TextSearchOperation (public) TextSearchEngine (core) (public) TextSearchVisitor (core) (public) AmountOfWorkCalculator (core) (public class, but package ctor) TypedResourceVisitor (core) (public class, but package ctor) TextSearchResultCollector (public) GroupByKeyComputer (package class, public method) GotoMarkerAction (package class, public method) TextSearchActionGroup (package class, public ctor) ReplaceAction (package class, public ctor) ReplaceDialog (public class, protected ctor) Which means that in order to plug in a new LabelProvider (of 60 loc), I had to copy eleven classes (totalling over 1700 lines), plus of course the TextSearchPage itself (almost 600 lines). Suggestions: a) Provide a public ctor, with a parameter LabelProvider, for class TextSearchResultCollector (perhaps defaulted via ctor-chaining, so that the current code of TextSearchPage could remain unaltered); then client code could simply copy the TextSearchPage, change the LabelProvider to be the one desired, and all would be well; b) Provide a new extension point (unclear to me exactly how, but surely it is possible) that would allow clients to specify that their SearchPage would use TextSearchPage (or any existing class -- clearly the current extension point can do that already), but that *also* allows clients to specify a second class, their LabelProvider -- then clients would not even have to copy the 600 lines of TextSearchPage

Files changed in fix:
org.eclipse.jdt.ui/core refactoring/org/eclipse/jdt/internal/corext/refactoring/util/QualifiedNameFinder.java org.eclipse.jdt.ui/ui/org/eclipse/jdt/internal/ui/propertiesfileeditor/PropertyKeyHyperlink.java org.eclipse.jdt.ui/ui/org/eclipse/jdt/internal/ui/util/PatternConstructor.java