Home » Eclipse Projects » Eclipse Platform » Surely the Search code can't be that badly factored?
| Surely the Search code can't be that badly factored? [message #22855] |
Tue, 29 April 2003 18:06  |
 Paul E. Keyser
Messages: 878
Registered: July 2009 |
Senior Member |
|
|
R2.0.2, Win2K
So, I found the extensionPoint org.eclipse.search.searchPages, and was
able to define a nice (useless) blank search page; all fine.
Now I wanted to make my search page do something, anything. So I
thought -- hey, I'll have it (note critical ambiguity!) display not the
file-name but the user-friendly 'node' name (our projects' files have
internal-only names; users interact with user-friendly names that are
stored *in* the files). Cool -- after a bit I found
TextSearchResultCollector (plus about four other TextSearchFoo classes),
and in TSRC, lines 134-136, which appears to be exactly what I need to
modify. I'll just copy
org.eclipse.search.internal.ui.text.TextSearchPage intact, and copy and
modify TextSearchResultCollector.
Then it got weird -- since TSRC either uses or is used by many
*package*-access classes, just to modify three lines, I wound up having
to *copy* the code for all of these classes: GotoMarkerAction,
GroupByKeyComputer, ReplaceAction, ReplaceDialog, TextSearchOperation,
and of course TSRC (almost 1000 lines). All but TSRC are of no direct
interest to me: I'd have been happy to accept whatever the existing
classes do. (I guess that the package-access is related to the
package-name "org.eclipse.search.internal.", but in fact many classes in
that package (or its subpackages) are public: e.g., SearchResultView,
TextSearchVisitor, StringMatcher, and TextSearchEngine -- it is
particularly odd to have TSO package but TSE, TSRC, and TSV public,
since TSO creates a TSE which creates a TSV which creates a TSRC, which
then uses a GMA (package), a GBKC (package), and a replaceAction
(package).
And it didn't even work, because SearchResultView appears to *ignore*
the description used by TSRC.
So, before I copy and cauterise another six classes of oddly
*package*-access code in vain, can anyone tell me how to just change the
String that is displayed in the SearchView? And am I just barking up
completely the wrong tree here?
(I shudder to think how messy it will be to write a SearchPage that does
anything but text-searches!)
Thnaks,
Paul K
|
|
|
| Re: Surely the Search code can't be that badly factored? [message #23423 is a reply to message #22855] |
Tue, 29 April 2003 20:30  |
Eclipse User |
|
|
|
Originally posted by: bob.objfac.com
"Paul T. Keyser" <rolarenfan@earthlink.net> wrote in message
news:3EAEBF33.DF1F681A@earthlink.net...
> (I shudder to think how messy it will be to write a SearchPage that does
> anything but text-searches!)
I did that. The non-text aspect didn't present much of a problem; as long as
the searching doesn't have to consider more than one resource at a time,
most of the design is going to be about the same. It's just a pity more of
the generic logic isn't captured in some kind of framework.
The API provided is the absolute minimum that will allow you to add a search
page. In fact, it's somewhat less than minimum. Many of the method arguments
are undocumented. I particularly enjoyed the string arguments destined for
MessageFormat for which the javadoc didn't explain how many arguments they
had or what the arguments meant. I had to locate and read a .properties file
to see how the API is used! After "start the search" the page writer is
given no help at all.
So I did what you did, I looked at Text search. However, I didn't try to
copy the internal code out and hack it. That is often like pulling a thread
in a sweater, as you found it. I just used it as a guide to how search works
in general.
Most of Text search seemed pretty sensible and modular to me. The only thing
that impressed me as "badly factored" - probably the same thing that
impressed you - was putting the text compare logic inline in the class that
drives the resource loop. That did seem a bit hacky, but it solved the
problem of where to put the variables that count down the progress. In my
design, I put the compare logic in a separate class and passed it an
interface to use for error and progress reporting. Also, some
simplifications are possible. The same information gets passed to classes at
multiple levels; at least one of those levels can be eliminated. I tried to
abstract the resource filtering mechanism a bit more and I wrote my own file
name wild-card matcher. I _think_ I did it because it wasn't easy to re-use
the one Text uses, but I'm not sure my motives were pure.
Would I have foregone the pleasure of writing all that code and just plugged
my compare logic into some search framework? You bet. I'll vote for that!
Bob
|
|
| |
| Re: Surely the Search code can't be that badly factored? [message #25966 is a reply to message #23593] |
Thu, 01 May 2003 16:28 |
| Eclipse User |
|
|
|
Originally posted by: bob.objfac.com
What do you mean by "change the text"? Each search page has a tab title, a
fixed Scope section and a variable-height per-page control that is drawn
above Scope. For the title and control, you can specify/draw any text you
want. In fact, you must; there isn't any way to re-use controls from the
existing pages.
Bob
"Paul T. Keyser" <rolarenfan@earthlink.net> wrote in message
news:3EAEF214.433C8B7E@earthlink.net...
> So, um, you never tried to change the text that the SearchView displays?
That
> would be one task (among many) that I have yet to work out how to do.
>
> But thanks for the encouragement on creating new Searchers.
>
> Thanks,
> Paul K
>
|
|
|
| Re: Surely the Search code can't be that badly factored? [message #27624 is a reply to message #25966] |
Mon, 05 May 2003 20:49 |
Paul E. Keyser
Messages: 878
Registered: July 2009 |
Senior Member |
|
|
Er, no -- the text displayed in the SearchView, i.e, the View that contains a
list of results (on each of which you can double-click and go to the result).
I wanted to display not the filename (e.g., TextSearchVisitor.java) but
something else (some text derived from the file, e.g.). I wound up figuring
out how to do it -- substitute a new LabelProvider at a certain point in (I
think but can't check right this minute) TextSearchResultsCollector -- but it
was sure not obvious until after I had read and stepped through about 6 or 8
classes, most with package-access (thus requiring that to add trace statements
I had to copy them to my WS and cauterize their imports, often requiring that
I bring in other classes I wasn't directly interested in).
Thanks,
Paul K
Bob Foster wrote:
> What do you mean by "change the text"? Each search page has a tab title, a
> fixed Scope section and a variable-height per-page control that is drawn
> above Scope. For the title and control, you can specify/draw any text you
> want. In fact, you must; there isn't any way to re-use controls from the
> existing pages.
>
> Bob
>
> "Paul T. Keyser" <rolarenfan@earthlink.net> wrote in message
> news:3EAEF214.433C8B7E@earthlink.net...
> > So, um, you never tried to change the text that the SearchView displays?
> That
> > would be one task (among many) that I have yet to work out how to do.
> >
> > But thanks for the encouragement on creating new Searchers.
> >
> > Thanks,
> > Paul K
> >
|
|
|
| Re: Surely the Search code can't be that badly factored? [message #28756 is a reply to message #27624] |
Thu, 08 May 2003 11:01 |
| Eclipse User |
|
|
|
Originally posted by: bob.objfac.com
I see. Good point.
(Eclipse is not a framework; it's an application with a plugin API. There's
a difference.)
Bob
"Paul T. Keyser" <rolarenfan@earthlink.net> wrote in message
news:3EB6CE40.EE4B22E1@earthlink.net...
> Er, no -- the text displayed in the SearchView, i.e, the View that
contains a
> list of results (on each of which you can double-click and go to the
result).
> I wanted to display not the filename (e.g., TextSearchVisitor.java) but
> something else (some text derived from the file, e.g.). I wound up
figuring
> out how to do it -- substitute a new LabelProvider at a certain point in
(I
> think but can't check right this minute) TextSearchResultsCollector -- but
it
> was sure not obvious until after I had read and stepped through about 6 or
8
> classes, most with package-access (thus requiring that to add trace
statements
> I had to copy them to my WS and cauterize their imports, often requiring
that
> I bring in other classes I wasn't directly interested in).
>
> Thanks,
> Paul K
>
> Bob Foster wrote:
>
> > What do you mean by "change the text"? Each search page has a tab title,
a
> > fixed Scope section and a variable-height per-page control that is drawn
> > above Scope. For the title and control, you can specify/draw any text
you
> > want. In fact, you must; there isn't any way to re-use controls from the
> > existing pages.
> >
> > Bob
> >
> > "Paul T. Keyser" <rolarenfan@earthlink.net> wrote in message
> > news:3EAEF214.433C8B7E@earthlink.net...
> > > So, um, you never tried to change the text that the SearchView
displays?
> > That
> > > would be one task (among many) that I have yet to work out how to do.
> > >
> > > But thanks for the encouragement on creating new Searchers.
> > >
> > > Thanks,
> > > Paul K
> > >
>
|
|
|
Goto Forum:
Current Time: Sat Nov 02 21:36:47 GMT 2024
Powered by FUDForum. Page generated in 0.03375 seconds |
] 
Search
Help
Register
Login
Home
