Bugzilla – Full Text Bug Listing
| Summary: | [validation] org.eclipse.wst.validation.validator support for facets | ||
|---|---|---|---|
| Product: | [WebTools] WTP Common Tools | Reporter: | Gary Johnston <GaryJohnston> |
| Component: | wst.validation | Assignee: | Vijay Bhadriraju <vbhadrir> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | delee, karasiuk, konstantin, lmandel |
| Version: | 1.5 | ||
| Target Milestone: | 1.5 RC1 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Gary Johnston
Adding e-mail thread comments... From kosta@bea.com: I don't know that there is a one answer for all situations, but I think > it would be of benefit to support the use of facets in most extension > points that refer to natures. Note that facets don't conflict with > natures, so it is always possible (although sub-optimal) to define a > nature to go along with your facet. The facet install delegate would add > the nature and the uninstall delegate would remove it. > > > > One thing that we should be consistent on is the schema that we use to > refer to facets in these extension points. This is especially important > since facets are versioned. It may be desirable to constrain to all > versions or just some. We can use syntax like following to represent a > reference to one or more versions of a facet. This is similar to the > syntax already used in the facets framework extension points and there > is api for handling version expressions. > > > > <project-facet id="foo" version="1.1,1.2,>=5.0"/> <!-The version > attribute is optional (not present means all versions). The comas in the > version attributes are ORs. --> > Adding comments from the e-mail thread... From gjohnsto@us.ibm.com: Re facet-referencing schema consistency: One possibility is for extension points like this to adopt/support generic enablement expressions (i.e., support <enablement> elements like org.eclipse.ui.viewActions, org.eclipse.ui.popupMenus, etc. do). The facet plug-in itself could contribute proopertyTesters that could be used to test for facet presence (or version range, or whatever is deemed useful) and for other things that are now done via filter/objectClass/nameFilter elements. Then, for example, one could contribute a facet-specific validator something like this: <extension point="org.eclipse.wst.validation.validator" id="com.whatever.myValidator" name="My facet-specific validator"> <validator> <enablement> <test property="org.eclipse.wst.common.project.facet.core.facetPresent" value="org.bar.someFacetID"/> <instanceof value="org.eclipse.core.resources.IFile"/> <or> <test property="org.eclipse.wst.common.project.facet.core.nameMatches" value="*.xml"/> <test property="org.eclipse.wst.common.project.facet.core.nameMatches" value="*.class"/> </or> </enablement> <run class="com.whatever.MyValidatorClass"/> <helper class="com.whatever.MyValidatorHelperClass"/> </validator> </extension> See the Platform Plug-in Developer Guide: Reference/API Reference/org.eclipse.core.expressions, Programmer's Guide/Advanced Workbench Concepts/Boolean expressions and action filters, etc. - Gary Another instance where this functionality is very much needed is the filter attribute of eclipse property pages. I used to be able to do the following: <extension
point="org.eclipse.ui.propertyPages">
<page
objectClass="org.eclipse.core.resources.IProject"
name="Page Name"
class="PropertiesPageClass"
id="propertiesPageID">
<filter
name="nature"
value="org.eclipse.jst.j2ee.web.WebNature">
</filter>
It would be very nice to be able to filter based on the installed facets.
(Please open a new bug if you feel that this is not the correct place for this functionality).
changing target from 1.5 M1 to 1.5 M5 to reflect new numbering system as we join Collisto. The support for the validator ext point understanding facets filters has been added. The J2EE validators (ejb, ear, war,app client and connector validators ) have been migrated to used facets. Any validators extending the validator ext point can define natures (one or more) or facet (one or more) filters or both. Here is sample facet element that the ejb validator defines
<facet
facetId="jst.ejb">
</facet>
Here are the different scenarios on how these filters work.
1. If just the nature(s) filter is defined then just like before the validator enables on the projects that has that nature
2. If both nature(s) and facet(s) filters are defined then the validator is enabled on projects with those nature(s) and facet(s)
3. If just facet(s) filters are defined then the validator is enabled on projects with only that facets ignoring any natures present on the project
4. If niether nature or facet filters are defined then the validator is free for any project.
Will be sending out a note soon to wtp-dev with this info.
(In reply to comment #5) > 4. If niether nature or facet filters are defined then the validator is free > for any project. I assume by "free" you mean that the validator will not be invoked for that project. I assume by "free" you mean that the validator will not be invoked for that project. Gary, By free i mean that the validator will be invoked on all projects in the workspace. The framework does filtering for natures and facets and if none are defined it mean the validator is valid for all kinds of projects in the workspace The facet filtering support added in 1.5 M5 will surely be useful, and is certainly a big improvement. Unfortunately, it does not handle my use case. I have a validator that should run if (and only if) any one (or more) of 3 (in my case) particular facets are present. Therefore, I need the facet filtering to let me specify the logical "or" of these three facets. But (if I understand it correctly) facet filtering currently supports only the logical "and" (i.e., a project must have *all* of the specified facets in order for that validator to be run). The facet filtering support needs to be more flexible in how it allows one to specify the enablement of contributed validators. Please see my comment #2, below, for a very flexible (and easy, I think) way to implement this. I tried to "roll my own" logical "or" behavior by contributing the same validator class IN 3 separate extensions (each specifying a different one of the 3 facets I care about). Unfortunatly, this did not work. Apparently, in the current facet filtering implementation, if more than one extender specifies the same validator class then only one of the extensions is enabled. To work around this I will have to define a couple of (otherwise unnecessary) subclasses of my validator class in order to be able to specify a different class for each of my 3 extenders. I don't think I should have to do that. Gary, What you understood is correct and its a AND condition rather than an OR. There is a reason why this was done this way, it was for our Prodcut specific facets i,e we wanted the validator only to be enabled if all the the facets defined in the validator were present. If i used the or condition then validators would also be enabled on projects that did not need them as they had one of the facets and this what you want. I may need add more filtering here to satify your condition i.e support for generic expressions like this
case 1
<facet
facetId="facet a">
</facet>
<or>
<facet
facetId="facet b">
</facet>
case 2
<facet
facetId="facet a">
</facet>
<and>
<facet
facetId="facet b">
</facet>
Will look into it...
Thanks, Vijay. I also want to be sure I was clear about how you could fairly easily add all the filtering flexibility anyone could probably every want merely by exploiting enablement expressions. That is, instead of explicitly adding support for an <or> capability, if you exploit enablement expressions then you extenders can use whatever enablement expressions they like (and you'll probably never again have to deal with anyone asking for more filtering flexibility). Again, please see comment #2 for details and references. Vijay, I agree with Gary. If the validator extension point is made to support the standard eclipse enablement expressions, the facets-based filtering will be taken care of as there is already a property tester for facets that plugs into this framework. May want to consider switching the validator extension point to use the enablement expressions and deprecate the existing filtering mechanism. Any progress or update on this? The support for enablement expressions is added to the validator ext point. The fix did not make into the M6 build and will be available in post M6, RC1 drivers. Thanks! Closing. |