Community
Participate
Working Groups
Some views may need to work with data that customizes its runtime behavior; let’s call these configurable or parameterized views. A good example is a configurable view that displays a Java Applet. This view's configuration (data) may include parameters that specify what applet to display, where to find the applet's JAR files, as well as various other applet configuration information. Configurable views may be useful without a configuration, but in a limited capacity. That is, a configurable view may use reasonable defaults for its parameters if a configuration is not found, however, the effectiveness of the unconfigured view is dependent on the function the view provides. For example, a configurable applet view would not be very useful unless a configuration is found that specifies what applet to display, but a configurable web browser view that allows for its decorations, home page, favorites, etc. to be configured may be of some use (e.g. browsing the internet). Eclipse 3.0 provides support for multiple instances of a view to be created and displayed within the same workbench page. All views have a unique identifier that distinguishes them from other views in the installation. Multiple instances of the same view are differentiated using a secondary ID. Multi views can serve as the basis for configurable views; however, they don’t provide a mechanism of associating a configuration with a multi view instance. A solution to this problem should consider the following: (1) The configuration should be available prior to the createPartControl() method being called. (2) Views should be able to access their configuration if it was added to a perspective with the org.eclipse.ui.IPageLayout interface or programmatically launched with the org.eclipse.ui.IWorkbenchPage.showView(String,String,int) method. (3) The Object type of the configuration should be narrow. That is, the configuration should not be of type Object. The Object type is too general and not conducive to creating a generic system for creating and setting view configurations. One possible option is an IConfiguration interface that contains IConfigurationItem Objects. Each IConfigurationItem has a String name and 0 or more String values and optional child IConfigurationItems. A couple of solutions to this problem are obvious and are as follows: (1) For each method in the org.eclipse.ui.IPageLayout interface that allows for a view to be added to a perspective create an overloaded method with the same signature but with the addition of the view's secondary ID. This will allow for the perspective creator to differentiate this view from other instances in that page (currently the secondary ID is null if added through IPageLayout). In addition, provide a repository where view configurations can be stored. This repository would use the combination of a view's unique identifier and secondary identifier to store a configuration. Configurations should be added to the repository before views are launched and a protected method could be added to the org.eclipse.ui.part.ViewPart class that allows for a View to easily obtain it's configuration. This solution meets all of the above requirements with a minimum amount of changes to Eclipse 3.0.1 source (I've implemented it). Shortcomings include that the configuration must be created and set prior to the view being created and there is no way to change the configuration after it's been set (unless you add a listener interface) (2) Add a method to the org.eclipse.ui.IViewPart interface to set the configuration (e.g. setConfiguration(<some_type)) or use the existing setInitializationData() method. This would require larger changes to the Eclipse code base. Much like solution (1) this would require additional methods to be added to the IPageLayout interface but instead of adding a String parameter for the view's secondary identifier it would be the configuration Object (and maybe the secondary identifier too). In addition, a way of obtaining a reference to the ViewPart prior to it's createPartControl() method being called would have to be added if launching a view programatically (e.g. IWorkbenchPage.showView()). This solution can satisfy all of the above requirements but would require more code changes than the first solution especially when launching a view programmatically.
Note that arbitrary properties can already be passed to a view, or any other extension instance via the data parameter of setInitializationData. See the Javadoc for IExecutableExtension for more details. In addition, arbitrary subelements could be put under the <view> element. These get passed in via the config parameter of setInitializationData. The PDE compiler may complain about such subelements since they don't satisfy the extension point schema, but it will work. Other usecases for passing initialization data to a view are more dynamic than what you propose, e.g. if views are showing a document, the app wants to pass the input element (similar to the way editors work). This use case would not be covered by a static configuration.
Nick, Correct, static data specified in a view's extension can be obtained in the setInitializationData() method but it's difficult to target subsets of this data to specific instances of a multi view, especially views that have null for their secondary identifier. Additionally, this data is static and can only be changed by updating the plug-in (plugin.xml or plugin.properties). I'm looking for a more dynamic system and a better way to set per instance data on a multi view. Currently, I only have use cases for setting this data once per instance, and displaying multiple instances on one page, but ideally you should be able to update or change the data while the view is active. The two solutions I proposed were just examples and starting points for discussion. They were the most obvious solutions and I don't expect either to be implemented. I agree with you that a generalized way of passing data/input/configuration to a view should be similar to the support for editors. I'm mostly concerned with the implementation satisfying the three requirements I listed in the description to this bug. Thanks.
Adding RCP tag as I assume this is for an RCP app, not a regular IDE plug-in.
Is there a plan to add this enhancement in 3.2? This is an important feature for our product.
Hi Beth, sorry this is not currently on the plan for 3.2. If this is important to you, please coordinate with Steve Wasleski.
Reassigning bugs in component areas that are changing ownership.
I will try to find time for this in 3.4.
In 3.3 part properties were added to both editors and views. Initially they can be accessed through IWorkbenchPart3. Also properties were added to perspective folders, although these were propogated all the way to the presentation. Maybe the part properties could be used if they could be set: 1) in the view definition, there could be a default 2) when calling showView and/or creating the view reference, maybe properties could be pre-set. Of course this depends on justifying that the view initial configuration is a property of the view :-) PW
Ran out of time for 3.4.
Remy is now responsible for watching the [ViewMgmt] category.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
