Bugzilla – Full Text Bug Listing
| Summary: | [Webapp] Support filtering in TOC and index | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Arnaud Lucien <IngedevTeam.fr> | ||||||||||
| Component: | User Assistance | Assignee: | Chris Goldthorpe <cgold> | ||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||
| Severity: | normal | ||||||||||||
| Priority: | P3 | CC: | aleherb+eclipse, cgold, ChrisAustin, mober.at+eclipse, wbprio, zhhaohh | ||||||||||
| Version: | 3.3.2 | ||||||||||||
| Target Milestone: | 3.6 M6 | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | Windows XP | ||||||||||||
| Whiteboard: | |||||||||||||
| Bug Depends on: | 76005 | ||||||||||||
| Bug Blocks: | 305828 | ||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Arnaud Lucien
We are currently working on this for Eclipse 3.6 as part of the work to support filtering by criteria. We are hoping to get this feature into Eclipse 3.6, we will know within the next few weeks if we can get it in. The plan is to have a button on the help web application to allow the contents to be filtered. A dialog will allow the user to either select the books to be displayed, filter according to criteria or by using a predefined filter. Criteria is a new feature in Eclipse 3.6 which allows entries to be added to the table of contents to specify which criteria a topic or book belongs to. The user can then filter the display based on those criteria. A predefined filter would be defined in a new extension point which implemented a class of type AbstractFilter allowing products to define interesting collections of topics to display. When a filter is turned on it affects the table of contents, the keyword index and the search results view. Thanks for the update, it sounds good! For our use-case, I think that allowing to select from a set of predefined filters would be good enough as a first step, thus greatly simplifying the UI. I think that end users are not interested in assembling complex queries or making tedious selections of books in the filter... they want simple predefined criteria, which an integrator has provided for them. When the filter and criteria definition is a separate extension point gluing the product and docs, even system integrators could add such criteria easily without modifying the components they integrate. I have marked bug 76005 as a prerequisite of this one, since it looks like that bug is about defining the filter/criteria infrastructure. Once the filtering infrastructure is in place, this bug can deal with the webapp. Created attachment 157166 [details]
Early version of implementation
I have attached a patch of this work in progress in the hope of getting early feedback. This patch contains an extension point which allows a filter to be defined. The extension point is called org.eclipse.help.base.scope. Infocenter results can be filtered based on one or more user defined scopes by adding a parameter ?subset=subset_name to the call to index.jsp. At this stage I do not have UI to switch scopes from within the infocenter. I will also attach a test project which defines a few filters.
Created attachment 157174 [details] Test project Here is a bundle which defines some scopes with the following ids: 'k' only topics and index entries whose title contains the letter 'k' are shown, along with their parent elements. 't', 'v' similar to 'k' except filtering on different letters of the alphabet. 'hk' similar to 'k' except that it only shows topics containing a letter 'k' whose ancestors all have that property. To test, apply the previous patch to Eclipse 3.6 and use the "subset" parameter to restrict the scope (note that I will probably end up calling this parameter "scope" but that name is already used internally for some of the jsp files so I need to change a few files to do that. Search scopes can also be used for filtering the table of contents and the index view. More than one "subset" parameter can be used at a time. For example if your infocenter is on port 8081 http://localhost:8081/help/index.jsp?subset=hk will only show those books whose title contains a letter 'k'. If you have a search scope named "PDE" help/index.jsp ?subset=k&subset=v&subset=PDE will only show those topics which contain both a letter 'k' and a letter 'v' and there ancestors that are in the PDE scope . (In reply to comment #6) > help/index.jsp ?subset=k&subset=v&subset=PDE will only show those topics which > contain both a letter 'k' and a letter 'v' and there ancestors that are in the > PDE scope . Intersection of search scopes is good, but what about union of subsets? In a large infocenter holding docs for multiple products, we'll want a user to be able and see docs for product1 OR product2 OR product3... Creating an object representing the union on two scopes is easy enough, the question is how to expose this to the user. One possibility is to allow boolean operators so you could have something like "?subset=scope1 and scope2". Well, in a UI with checkboxes for several predefined subsets, I'd intuitively expect that checking multiple boxes would give me the union of all subsets. I'm less sure about the use-case for intersecting subsets... I've had a chance to try out the implementation, and it looks very cool. I was able to build a filter for some Rational documents - using a meta tag within the help ITopic page. Everything seemed to work in this test case for the inScope(ITopic topic). I did notice that because I didn't filter the TOC's, any TOC with no children causes the 'Loading Please Wait' message to appear indefinitely. Otherwise, so far it looks pretty good. It is important to note that by building your own scopes using the API you can deal with the intersection versus union case within a single subset, by adding your own logic. Thus, its not a show stopper for us as-is. Created attachment 157465 [details]
Updated implementation
This contains a fix for the Toc with no children problem and adds quite a few JUnit tests. I have also changed the parameter name from "subset" to "scope".
I think the implementation and API is looking solid and I'm planning on committing this layer at the end of this week so we can then work on merging in the criteria code in and adding UI.
I have committed the patch, I will wait until this is integrated with the changes for Bug 76005 before I close as Fixed. A dialog to allow the users to select filters has now been committed. We would like to get feedback on the UI since there is a whole milestone available to make changes and polish as necessary. I have opened Bug 303105 to capture that feedback. Resolving as Fixed. Created attachment 159389 [details]
Toc with criteria for testing
If you install this bundle and add the lines below to you pluginCustomization.ini file you will be able to see criteria in the SDK.
# Filtering by criteria
# Set true to enable criteria filtering, otherwise set false
org.eclipse.help/enableCriteria=true
# List all the supported criteria names, separated by comma
org.eclipse.help/supportedCriteria=platform,version
I'm a little confused, why would anybody want to disable criteria? If their documentation did not include any criteria then we don't want to show the right hand side of the scope selection dialog. Currently the Eclipse SDK documentation does not have criteria. |