Community
Participate
Working Groups
On a loose common wizard extension, I should be able to specify a navigator content extension to attach or group myself too. That would give extenders the opportunity to tie into an existing content extension and limit their exposure.
Created attachment 40213 [details] Adds menuGroupId, associatedExtensionId to extension point and parses these new attributes
The fix here required two new attributes to the schema for commonWizard (in the org.eclipse.ui.navigator.navigatorContent). The functionality for one of these attributes is already implemented (associatedExtensionId) and is now just exposed to be set by the attribute. The other attribute (menuGroupId) required a small addition to the CommonWizardDescriptor class to parse this attribute, and a small update to the WizardActionGroup to use this information when generating the new/import/export submenus. No clients will be broken as a result of this API addition. No clients are required to take advantage of it, but it does provide a way to improve the scalability of the API. Currently, the menu groups are just Separator-delineated sets in the popup menu, but in a future release, with sufficient feedback from the user community, this could use submenus to provide greater scalability. No API classes had their public API updated as a result of this change. WizardActionGroup was the only public API class who had some of its internal implementation updated. I would like to drop this for RC3.
Is this a stop ship? At this point, unless we are certain that consumers will be unable to proceed without this, we should defer to R3.2.1.
We contribute a navigator extension in WTP for J2EE. We have extenders on top of WTP who want to contribute wizard actions and menu's to this WTP content extension. However, there is no way to do this. They can only add themselves at a top level, meaning, its a performance hit for one, and there may be a large number of extensions who show similar objects but don't care about these specific wizards or actions which may be out of context, so they don't want them cluttering the menu's. Having the proposed fix added to the navigator API will make this very easy to resolve.
It is important for EGL to have sub grouping. Without it, the context menu(New) becomes messy, because there are multiple content extention providers. The menu displays alphabetically, so the menu contributions are intermingled together. In the case of EGL project, an EGL user has to sort through the EGL action, java action and possible other contributor actions, which they may not care about. It has become confusing and not user friendly to them. Also as the menu list grows, it will become unusable. The grouping function will solve the issue by making the contribution much more scalable.
+1 to API addition, needs review by two component leads.
Can this be approved in time to be included in the next Platform/UI build submission (3:30 today)?
Is the patch complete? It only seems to add a method to an interface but doesn't have any extension point changes.
Created attachment 40276 [details] Adds menuGroupId, associatedExtensionId to extension point and parses these new attributes
The wrong patch was initially attached. I've corrected this.
+1
Fixed and released.
Verified.
