Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] Re: wtp-dev Digest, Vol 9, Issue 88

I would suggest continuing this discussion within the context of the associated bugzilla:

That way, none of the suggestions and information is lost.  All interested parties should add themselves as CC's to recieve the notes.


John Lanuti
Software Engineer, IBM Rational
t/l 441-7861

"I know this lady way down in my country.
She is so pretty that my eyes throw disguises at me.
Now we will sit and we'll wonder about our future,
But now I'm thinking that today sounds fine to me."  - Of A Revolution

Gary Johnston/Raleigh/IBM@IBMUS
Sent by: wtp-dev-bounces@xxxxxxxxxxx

11/30/2005 09:00 AM

Please respond to
"General discussion of project-wide or architectural issues."

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

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:




   name="My facet-specific validator">



       <test property="org.eclipse.wst.common.project.facet.core.facetPresent" value=""/>

       <instanceof value="org.eclipse.core.resources.IFile"/>


         <test property="org.eclipse.wst.common.project.facet.core.nameMatches" value="*.xml"/>

         <test property="org.eclipse.wst.common.project.facet.core.nameMatches" value="*.class"/>



     <run class="com.whatever.MyValidatorClass"/>

     <helper class="com.whatever.MyValidatorHelperClass"/>



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_______________________________________________
wtp-dev mailing list

Back to the top