I would suggest continuing this discussion within the context of the associated bugzilla: https://bugs.eclipse.org/bugs/show_bug.cgi?id=+118448
That way, none of the suggestions and information is lost. All interested parties should add themselves as CC's to recieve the notes.
Thanks,
John Lanuti
Software Engineer, IBM Rational
[EMAIL PROTECTED]
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/[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED] 11/30/2005 09:00 AM
|
|
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" <[EMAIL PROTECTED]>
> Subject: RE: [wtp-dev] Re: org.eclipse.wst.validation.validatorsupport
> for facets?
> To: "General discussion of project-wide or architectural issues."
> <[email protected]>
> Message-ID:
> <[EMAIL PROTECTED]>
> 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,>=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
[email protected]
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________ wtp-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/wtp-dev
