Community
Participate
Working Groups
I would like support for multiple propertyContributors with the same contributorId. Currently you can add tabs from separate plugins to the same propertyContributor, but you cannot use a different TypeMapper, LabelProvider or ActionProvider. In TabbedPropertyRegistry only 1 of each of the above attributes is stored. So, in the constructor the last configurationElement defined wins in the for loops that sets those attributes.
I am wondering how the multiple contributors would work. For example, I have a red box on the contributor and I have a type mapper to map it to green box when selected. If I have a second type mapper, which one gets asked? Who wins? I also display <green box> in the title bar as returned by the label provider when I select the red box. If I have a second labelProvider, who wins?
I'll try to explain thoughts on tabbed properties, but at this point I don't consider this enhancement to be as high a priority. At the least I need the patch for bug 156277 to be in the release. I am thinking that multiple contributors could be a way to have context in the tabbed properties. So, take my example with adding tabbed properties support to the JavaEditor and then in my own plugin adding support for editing Java Persistence API (JPA) annotations. The Tabbed Properties could have some kind of context chooser in the menu bar (a drop down or tool bar buttons, something like that) with the options of Java and JPA. If you choose Java then the Java contributor's label provider, filter, tabs, sections would be used. If you choose JPA then its tabs would be shown and its label provider, filter, etc would be used. If there were only one contributor, the tabbed properties would be shown exactly as they are now. Bug #156277 would allow me to support tabbed properties in the JavaEditor by providing a StructuredSelectionProvider. In the JavaEditor implementation it would convert the ITextSelection to a StructuredSelection containing an IJavaElement. In my JPA plugin the StructuredSelectionProvider implementation would convert the ITextSelection into a Structured selection containing a JPA model object. If only bug 156277 is fixed, I can handle this, but my section extensions will have to use IJavaElements as the input and then I'll have to convert in my ISection implementations to my own JPA model object. How does this sound?
(In reply to comment #2) > I'll try to explain thoughts on tabbed properties, but at this point I don't > consider this enhancement to be as high a priority. At the least I need the > patch for bug 156277 to be in the release. OK, I will comment on bug 156277 then.
After more investigation I have decided a fix for this bug is necessary for our project to use the tabbed properties with the JavaEditor. Having IJavaElements as the input is not enough information to create the appropriate tabs for my context. Currently all I have tabs for are IType and IField/IMethod. What I need are tabs based on the JPA annotations that exist on an IType or an IField/IMethod. So, if the IType has an Entity annotation (the input would be my Entity model object), then I would show different tabs than if the IType had an Embeddable annotation. The idea is that I need to be able to provide a separate StructuredSelectionProvider in the JPA plugin than the one defined in the JavaEditor plugin with bug 156277. I would like the properties view to be as fine-grained as necessary based on the text selection.
(In reply to comment #1) > I am wondering how the multiple contributors would work. > > For example, I have a red box on the contributor and I have a type mapper to > map it to green box when selected. If I have a second type mapper, which one > gets asked? Who wins? > > I also display <green box> in the title bar as returned by the label provider > when I select the red box. If I have a second labelProvider, who wins? > Still do not understand why multiple propertyContributors with the same contributorId is required and how it will work.
The JDT UI bug 154781 explains the multiple property contributors use case pretty well. I will try here as well. Consider a java file that has annotations for JPA and JAXB. Here is an example I found http://www.devx.com/Java/Article/34069/0/page/5, the bold annotations are JPA, the others are JAXB, and where there are no anotations there is a default for both JPA and JAXB. A JPA plug-in and JAXB plug-in could each contribute to the JavaEditor properties view and add their own tabs. We would need some sort of context to achieve this since they would each need to define their own ITypeMapper, ILabelProvider, etc. The context could be chosen by the user via a drop-down menu on the tabbed properties view. So the user would choose the JPA context and select a java type in the editor that includes an @Entity annotation. They would see tabs such as Entity, Inheritance, Generators, SecondaryTables, and Queries which are all JPA related things that can be added as annotations to the java type. If they chose the JAXB context they would see a tab for XMLType, etc. The JPA model and JAXB model would be different so they would each need to define their own ITypeMapper to take a java IType/IField/IMethod and turn it into the appropriate Entity or XmlType. As a workaround, we (Dali, a sub project of WTP) currently have a JPA specific view called the JPA Details View. We did not add the Tabbed Properties to the java editor in our own plug-in because we felt this would not be playing fairly. If we did that and another plug-in did the same, which one would win? The ultimate solution here is to have the java editor use the tabbed properties and allow others to contribute to it as well. Do you have other ideas on how we can achieve this functionality in an eclipse-friendly way?
(In reply to comment #6) > The ultimate solution here is to have the java editor use the tabbed properties > and allow others to contribute to it as well. > > Do you have other ideas on how we can achieve this functionality in an > eclipse-friendly way? > I think you answered your question here. The editor should have a single contributor that third parties contribute tabs and sections to. The editor also defines the selection model that will be used.
