Community
Participate
Working Groups
Background/Usecase: WebTools has a concept of a "faceted project". A project facet is basically a marker that's similar to a project nature. We need to have a way to filter project property pages based on whether a facet is present on a project. What I tried: 1. Created an adapter for IProject -> IFacetedProject. 2. Created an impl of IActionFilter that knows how to filter on facets. 3. Created an adapter for IFacetedProject -> IActionFilter using the impl of IActionFilter from (2). Test case: <extension point="org.eclipse.ui.propertyPages"> <page adaptable="true" class="org.eclipse.wst.common.project.facet.ui.internal.FacetsPropertyPage" id="org.eclipse.wst.common.project.facet.ui.internal.FacetsPropertyPage" name="%project.facets" objectClass="org.eclipse.wst.common.project.facet.core.IFacetedProject"> <filter name="facet" value="jst.web"> </filter> </page> </extension> What I am seeing: My action filter is not getting called, so I put in the debugger. I placed the breakpoint at the start of the PropertyPageContributorManager.contribute() method. The getContributors() call appears to detect that IProject can be adapted to IFacetedProject, so my property page contribution is in the initial list of contributors. However when the code then procedes to check whether the contribution is applicable using RegistryPageContributor.isApplicableTo() method, the IProject isn't first adapted to the type specified by the contributor (IFacetedProject in this case). This means it adapts IProject to IActionFilter and picks up the wrong IActionFilter. Is this a bug or expected behavior? Is there some other way that I can get this accomplished? Note that this is related to https://bugs.eclipse.org/bugs/show_bug.cgi?id=106839. Setting the severity pretty high because we really need some way to do this and there doesn't appear to be a way. If at all possible, we'd like this to be addressed for 3.1.2.
https://bugs.eclipse.org/bugs/page.cgi?id=fields.html#bug_severity. Moving to enhancement. This is actually by design. From the javadoc: "The workbench will retrieve the filter from the selected object by testing to see if it implements <code>IActionFilter</code>. If that fails, the workbench will ask for a filter through through the <code>IAdaptable</code> mechanism. If a filter is found the workbench will pass each name value pair to the filter to determine if it matches the state of the selected object. If so, or there is no filter, the action will be added to the context menu for the object." Changing this might break existing clients. What you probably need is org.eclipse.core.expression support in the property page contribution, which I believe makes this a duplicate of Bug 106839. Bug 106839 comment #1 asks for more details, but no one has replied in the past five months. Moving to Tod [PropertiesDialog].
I added a comment to 106839 to clarify what is being asked, although in my opinion the original comment was pretty clear that what was being asked is to support the expressions in the propertyPages extension point.
A workaround would be to: - set a persistent property on the project (see IResource.setPersistentProperty) - test for that using the existing IActionFilter registered for resources (see IResourceActionFilter.PROJECT_PERSISTENT_PROPERTY)
It does not appear that the workaround suggested in #3 will work. Persistent properties appear to be serialized under the workspace metadata. This means that properties would be lost when the project is moved to a different workspace, such as in a team environment.
I'm not sure how facets relate to natures, but when a project is loaded from the repository, its nature gets to configure the project (e.g. add builders). If the nature delegated to the facets, facets could define any properties they require.
cc'ing John so he's aware of the nature/facet conversation.
I believe you have an incorrect understanding of how natures function. The configure method on a nature only gets called when it's first added to the project. It will not get called again when the project containing the nature is pulled from the repository. Unless you are suggesting that people don't source control project metadata, which doesn't work for a variety of reasons. There is however a workaround for this that involves natures. It involves defining a nature to go with the facet and having the facet add the nature to the project during facet install. This will work in the short-term (WTP 1.0.1/Eclipse 3.1.2), but is not a good long-term solution.
Forgot to add... once the nature is added, you can use it to filter property pages on.
I think adding exression support in the propertyPages extension (bug 106839) would be the best and most extensible long term solution.
This is no longer necessary since https://bugs.eclipse.org/bugs/show_bug.cgi?id=106839 has been resolved.
