Community
Participate
Working Groups
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.
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.
Chris G - can you review this patch, as it will become API?
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[].
Created attachment 178065 [details] Patch to add IHelpScopeProducer (v2) Implemented the changes Chris G suggested.
Patch committed to HEAD.
Changing milestone to M3 since the changes did not get tagged for release until today.
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?
(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.
