Bugzilla – Full Text Bug Listing
| Summary: | [Help][Search] Allow pre/post processesing steps to the Help Search button | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Chris Austin <ChrisAustin> | ||||||||
| Component: | User Assistance | Assignee: | Chris Austin <ChrisAustin> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | cgold, esirois, zhhaohh | ||||||||
| Version: | 3.7 | ||||||||||
| Target Milestone: | 3.7 M5 | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Windows XP | ||||||||||
| Whiteboard: | |||||||||||
| Bug Depends on: | |||||||||||
| Bug Blocks: | 326001 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Chris Austin
That's great. I also think about this. I hope that, search input box should be more like google. If you input 'app', then maybe 'apple' and 'application' wil be shown in drop-down list, which will be more useful for user to choose proper search phrase. Your proposal just provides such solution. And I think we should also think about more enhancement of search phrase hinting. Do you envisage the preprocessing taking place in a user defined method which takes the search string ( and possibly also locale ) as a parameter and returns another string as the result? Created attachment 184194 [details]
Initial implementation patch
I have created an initial implementation of this, which allows a developer to use the 'org.eclipse.help.searchProcessor' extension point to contribute an AbstractScopeProcessor class. This class has preSearch() and postSearch() methods which return a String that can be used in the search frame.
Unfortunately, I do not have a good way to duplicate this effort for the help view - I cannot have a preSWTSearch which returns a Composite because then help would depend on the eclipse ui, which is not what we want at all. So any suggestions on a good solution are welcome. Perhaps some kind of pseduo markup language that the help view could interpret and turn into a ui? Might be too large for this bug.
I looked at the attachment briefly - a few comments: You need @since tags in the API classes. You can turn on API checking in the preference page for Plug-in Development/API Baselines and set the API baseline to Eclipse 3.6. With API checking enabled this is reported as an error. I don't like the idea that the extension point would work differently in the help Webapp and in the Help View - we should be working to reduce the number of differences between Webapp and Help View, not increase them. I understand the preSearch() function but not postSearch(). I would think that the most useful thing you could do post search would be to allow the extension point to change the weight of each search result or exclude results completely. (In reply to comment #4) > I looked at the attachment briefly - a few comments: > > You need @since tags in the API classes. You can turn on API checking in the > preference page for Plug-in Development/API Baselines and set the API baseline > to Eclipse 3.6. With API checking enabled this is reported as an error. Thanks for the feedback Chris. I will add the tags and turn on API checking. > I don't like the idea that the extension point would work differently in the > help Webapp and in the Help View - we should be working to reduce the number of > differences between Webapp and Help View, not increase them. I agree - id prefer the extension point be the same, so I am open to suggestions on how to handle this > I understand the preSearch() function but not postSearch(). I would think that > the most useful thing you could do post search would be to allow the extension > point to change the weight of each search result or exclude results completely. There are a few ideas in Rational that would use postSearch. For example, one would be to never have an empty result set. If 0 hits came back to the postSearch method, a link to something else can be put up in its place. Or, a set of sponsored results of terms that are commonly associated with certain important topics. What if we made swt an optional dependency of org.eclipse.help? This way, if the help is being run without the ui, the preSWTSearch, postSWTSearch would just not be called. Thoughts? Created attachment 186441 [details]
Implementation V2.0
I have changed the AbstractSearchProcessor class to now return a SearchProcessorInfo class, which can change the search query or supply alternative search expressions. The Web UI and Help View can both consume the alternates and display them appropriately, without the need for ui dependencies as I had originally thought.
In this patch, the search processor has the opportunity to modify a search string, provide alternate search expressions, or modify the search result set.
I'm working on building a client based on the initial patch. Here are some things I noticed. In the schema the class implements org.eclipse.help.AbstractSearchProcessor, this should be extends, not implements. searchView.jsp has a compilation error. I was able to test in the help view and it was easy to create a client. The user interface was well designed and user friendly. I felt like I needed more Javadoc for the methods in AbstractSearchProcessor, particularly for methods like getId() and getParticipantId(). The other question is where the extension point should live - org.eclipse.help or org.eclipse.help.base. Right now we seem to have an approximately equal number of extension points in each of these two bundles. There is a slight preference for putting things in org.eclipse.help.base ( which already has a package org.eclipse.help.search )since some RCPs which do not use the help system still have a dependency on org.eclipse.help but this is not a major issue. (In reply to comment #8) > In the schema the class implements org.eclipse.help.AbstractSearchProcessor, > this should be extends, not implements. Agreed - fixed for next patch. > searchView.jsp has a compilation error. I don't see a compilation error in my env - can you elaborate on what you see? > I felt like I needed more Javadoc for the methods in AbstractSearchProcessor, > particularly for methods like getId() and getParticipantId(). These fields are in the Lucene hits, and I am not sure what they do or if they are even needed in the results view. Maybe we should remove them from the ISearchResult interface? > The other question is where the extension point should live - org.eclipse.help > or org.eclipse.help.base. Right now we seem to have an approximately equal > number of extension points in each of these two bundles. There is a slight > preference for putting things in org.eclipse.help.base ( which already has a > package org.eclipse.help.search )since some RCPs which do not use the help > system still have a dependency on org.eclipse.help but this is not a major > issue. Slight preference is enough for me to move it to base - thanks for the tip. Created attachment 187159 [details]
Implementation V3.0
Comment on attachment 186441 [details]
Implementation V2.0
Fixed compile error, left participant and id alone.
Patch committed to HEAD *** Bug 308579 has been marked as a duplicate of this bug. *** |