Bugzilla – Full Text Bug Listing
| Summary: | Need PDE Extension Points | ||
|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Frederic Plante <fplante> |
| Component: | UI | Assignee: | PDE-UI-Inbox <pde-ui-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | danrubel, ed.burnette, pattathe, sikkar, voutsin |
| Version: | 3.0 | ||
| Target Milestone: | 3.0 M9 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 52625 | ||
This is an interesting request. Have you tried to create a new template yourself? One of the reasons it is still experimental is that we are not sure if it meets the needs of sufficient number of ISVs. We have provided a number of templates ourselves, but are not sure if the current support is useful enough for others. *** Bug 45681 has been marked as a duplicate of this bug. *** I unfortunately have not tried creating templates yet. The designation 'experimental' allows us to change the API without the formal process + migration consideration. Since you are the first user actually expressing interest in using the API, we would appreciate your feedback - that would help us to get to the API status faster. In addition, more detail on your use case would be beneficial (actual product names can be mangled if condfidential as this is an open forum). *** Bug 49597 has been marked as a duplicate of this bug. *** Some more details: * The implementation of the wizards often needs a way to gather the list of extensions from workspace and runtime plug-in extensing a given extension- point. * Making the PluginReference utility class public would be very handy * Adding product specific code generators will result in an increase of such wizards, making categorization of the code generators a welcome addition. Could be accomplish by opening the existing categorization mechanism (allow creation of New PDE Project Wizard for given categoy), or group code generators by a new sub-categoy in the Code Generators page. As per Wassim's suggestion, am adding my comments to this bug report. I am using the 2 PDE extensions - org.eclipse.pde.ui.projectGenerators and org.eclipse.pde.ui.templates to create my own plug-in project using my own template (similar to HelloWorld, Multi-page editor, etc.) In the page before the page that actually allows selection from the list of available templates there is a text field called 'Class Name:' where the user specifies the name of the plugin class. Its default value is '<projectname>.<projectName>Plugin' - which can be changed by the user. I have a requirement where in my template file I need to access the name of the plugin class. Thanks, Rajeev Actually, I think there is a way. I checked the code and there seem to be some predefined replacement variables that can be used in code. They are defined in AbstractTemplateSection as: pluginClass pluginId pluginName packageName I may be mistaken (having written this code long time ago :-), but see if you can access these variables in template files by referencing them as $pluginId$, $pluginClass$ etc. You can access all other template options you provide yourself the same way - these are just predefined for you. Another extension should probably be made public so products can expose source code: org.eclipse.pde.core.source. Note that resolving 52894 is probably even better given products generally expose APIs, their javadoc, but not their source code. See also bug 53468 which, among other things, adds an rcp attribute to the projectGenerators extension. Even if the extension points were non-experimental, the inability to subclass existing PDE wizards means unnecessary duplication of code. For bug 53468 I had to change the internal classes in the PDE UI plug-in to create the kind of wizards I wanted. I have a requirement where I need to extract information from the plugin.xml corresponding to a plugin project thats still being developed i.e. a plugin thats in the workspace and has NOT been deployed yet. The situation is similar to the Hello World plugin. When you create the HelloWorld plugin the user provides the name and location of the action class. Here is a snippet of the plugin.xml: <action label="&Sample Action" icon="icons/sample.gif" class="hello.actions.SampleAction" tooltip="Hello, Eclipse world" menubarPath="sampleMenu/sampleGroup" toolbarPath="sampleGroup" id="hello.actions.SampleAction"> </action> I want to extract the string corresponding to the class tag i.e. "hello.actions.SampleAction" in this case. Here is the code snippet I am using to do this: WorkspaceModelManager manager = PDECore.getDefault().getWorkspaceModelManager(); IModel model = manger.getWorkspaceModel(project); IPluginBase plugin = ((IPluginModelBase)model).getPluginBase(); IPluginExtension[] extensions = plugin.getExtensions(); ... ... As you can see this requires use of internal classes. So, either these classes need to be made public, OR there needs to be some alternate way to do this. I have been communicating with Wassim regarding this issue. I am having trouble designing the portion of the request that asks for the ability to 'Edit' the extension by opening the custom editing wizard. The problem is as follows: we have the ability to run custom wizards that can generate any number of extensions from within the manifest editor. However, once generated, these extensions and their elements are normal in every way i.e. are no different than any other extensions in the file. Therefore, we have a problem finding out how to match these extension up with the custom editing wizards. Not sure I understand. I assume the core of the problem here is that we are trying to implement the functionality using existing extension-points and wizards, which I don't think is possible for two reasons: 1) The potential 1:* nature of wizards 2) Existing creation oriented wizards cannot be reused as-is for editing since the logic is slightly different We probably need a new extension-point for these edit wizards to expose the extensions they can edit. There are several question then: 1) Will these wizards claim that they can edit any extension into the extension point they advertise? In other words, if you claim that you can provide a custom wizard for editing 'org.eclipse.ui.views' extension points, you will need to handle all the views, not just those created by your own 'newExtension' wizard. 2) If there are more than one editing wizards for the same extension point, one 'Edit...' button would not do. We would need to use a selection wizard where the wizard/editor is chosen first. 1) This is a reasonable assumption that should be part of the contract 2) In most cases, edit capabilities will be provided by a single plug-in. We should probably optimize UI for these cases. e.g. A pulldown menu with a list of available editor wizards "à la" Run toolbar item. The default choice could be the last wizard used for a given extension-point. This would ease the cases where there is only one choice. A question: The new manifest editor now supports moving property fields in the right portion of the page (replacing the property sheet completely). These fields are computed based on the extension point schema for the selected element. In case the extension editor has been registered for the extension point, should these fields be shown? In other words, should we still leave the user an option to hand-edit values of the element attributes in addition to doing it by pressing the 'Edit...' button? I think we should never prevent users from using standard PDE base functionality in case 1) The wizard only handles a subset of the extension-point's functionality. This case is likely if the extension edit wizard is targetting an older version of Eclipse. 2) The wizard may be broken or not optimal and cannot easily be disabled since part of a larger plug-in OK, done. Here is the design: 1) The existing extension point (newExtension) now accepts new element 'editorWizard'. The expected attributes are 'id', 'name', 'class', 'icon' and 'point'. The wizard can also have a child 'description' just like the 'new extension' wizard. 2) 'class' attribute is expected to implement IExtensionEditorWizard interface. This interface is similar to IExtensionWizard but its 'init' method accepts the third argument (the current selection in the Extensions page). 3) 'point' attribute is used to declare the extension point that the editor wizard is capable of handling 4) A new button 'Edit...' has been added to the Extensions page. It is disabled by default end enables when an element or extension is selected in the tree for which there is at least one editor wizard registered 5) If there is only one editor wizard, 'Edit...' will directly open it. If there are 2 or more editor wizards registered for the same extension point, a two-pane selection wizard comes up. The left pane lists all the matching editor wizards, while the right shows the description for the selected one. Pressing 'Next' switches into the selected wizard as in point 4). 6) The implementation of 'finish' method in the wizard is supposed to change the model using its APIs (for add/remove elements, change their properties etc.). This will cause model to be dirty and thus make the editor dirty. There is no need to do anything else - when the user saves the editor, the changes will be flushed into the document. My goodness. All that work and we only get to increment the number of bugs fixed by 1 ;-) Thanks Dejan. Yeah, I even restored the shared ListSelectionPage by pushing the common code down from TemplateListSelectionPage (names not necessarily as in real life). So you got new design + refactoring for the price of one. |
Products exposing extension-points cannot always expect their extensibility users to be savvy Eclipse developers. These products need to offer a simpler UI than the manifest editor's for the creation/editing of extensions. To this end, the following enhancements are proposed: 1) Make the PDE extension points public as opposed to "experimental" : a) Plug-in code generators extension b) Template extension (for the custom plug-in wizard) c) Extension wizards extension 2) Expose a new extension point to enable wizard based editing of an extension. The extensions would be invoked from a new "Edit" button added to the Extension page of the plug-in manifest editor.