Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 322669

Summary: [Help] Allow for dynamic filter scopes to be created at runtime
Product: [Eclipse Project] Platform Reporter: Chris Austin <ChrisAustin>
Component: User AssistanceAssignee: Chris Austin <ChrisAustin>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: cgold, mober.at+eclipse
Version: 3.7Flags: ChrisAustin: review? (cgold)
Target Milestone: 3.7 M3   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
Patch to add IHelpScopeProducer
none
Patch to add IHelpScopeProducer (v2) none

Description Chris Austin CLA 2010-08-13 11:56:59 EDT 
Currently, the only way to add filters programatically is via the org.eclipse.help.base.scope extension point.  This requires that all filter scopes be computed at compile time, defined in their own class, and added to the extension registry.

We have a scenario where there will be many potential scope filters available for a user to apply, but the list of these scopes depends on what content is found.  It would be nice if we could define an 'IHelpScopeProducer' to return a list of scopes which are created at runtime.  This way we don't have to create many extra extension point registry entries, or extraneous java classes.
Comment 1 Chris Austin CLA 2010-08-13 11:59:32 EDT 
Created attachment 176567 [details]
Patch to add IHelpScopeProducer

This patch allows for an IHelpScopeProducer to be registered via the scope extension point, and users of IHelpScopeProducer implement the getScopes() method to return a list of runtime-generated scopes.
Comment 2 Chris Austin CLA 2010-08-18 09:23:32 EDT 
Chris G - can you review this patch, as it will become API?
Comment 3 Chris Goldthorpe CLA 2010-08-18 12:30:44 EDT 
I have a few comments on the patch.

The concept of adding this extension point seems to be reasonable and is a logical extension of existing functionality.

The bundle version of org.eclipse.help.base needs to be increased to 3.6.0, if you turn on API tooling this will show up as an error, and it would also show up as an error in the nightly build.

The other thing that doesn't feel right is the use of the static variable "locale" in the ScopeRegistry class. In an infocenter requests could come in from different locales and as I understand the code whichever locale the first call comes from will be used to generate the ids of the ScopeHandle objects.
The function getInstance(Locale loc) ignores the locale parameter on all but the first call. Maybe a better way to get the id would be to turn ScopeHandle into an API class ( AbstractScopeHandle ) and have IHelpScopeProducer return an array of type AbstractScopeHandle[].
Comment 4 Chris Austin CLA 2010-09-02 12:53:28 EDT 
Created attachment 178065 [details]
Patch to add IHelpScopeProducer (v2)

Implemented the changes Chris G suggested.
Comment 5 Chris Austin CLA 2010-09-02 15:09:32 EDT 
Patch committed to HEAD.
Comment 6 Chris Goldthorpe CLA 2010-09-20 17:16:12 EDT 
Changing milestone to M3 since the changes did not get tagged for release until today.
Comment 7 Martin Oberhuber CLA 2010-11-30 22:00:00 EST 
This feature will be interesting for us.

Are there going to be any Unittests for the feature (I don't know the existing UA unittest infrastructure). I'm also wondering why the contribution is marked iplog+ when it looks like it's from a committer?
Comment 8 Chris Austin CLA 2010-12-01 09:09:47 EST 
(In reply to comment #7)

> Are there going to be any Unittests for the feature (I don't know the existing
> UA unittest infrastructure). I'm also wondering why the contribution is marked
> iplog+ when it looks like it's from a committer?

Yes there should probably be some unit tests for this - probably a new bug should be opened for that.

As far as the iplog+ goes, that was my misunderstanding of the process.  I will remove it.