[wtp-dev] Re: wtp-dev Digest, Vol 9, Issue 88

[Gary Johnston <gjohnsto@xxxxxxxxxx>]

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

---

Gary Johnston Team Lead, Web Application Diagramming, Struts Tools, Web Application Sketching Rational Application/Web Developer 919 254-0027 (t/l 444)

IBM Rational Software IBM Software Group Research Triangle Park, NC

> Date: Tue, 29 Nov 2005 16:31:49 -0800
> From: "Konstantin Komissarchik" <kosta@xxxxxxx>
> Subject: RE: [wtp-dev] Re:   org.eclipse.wst.validation.validatorsupport
>    for   facets?
> To: "General discussion of project-wide or architectural issues."
>    <wtp-dev@xxxxxxxxxxx>
> Message-ID:
>    <4C2F1577F2EF2840A9AE9EC61860C8810212CB9D@xxxxxxxxxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="us-ascii"
> 
> 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,&gt;=5.0"/>
<!-The version
> attribute is optional (not present means all versions). The comas
in the
> version attributes are ORs. -->
> 
>  
> 
> - Konstantin