# Content Model Annotations Framework

### Overview

The purpose of the JSF content model annotations framework is to provide a mechanism by which Eclipse plugin developers can attach the required meta-data to support improved tooling for XML content models. XML Content models (DTD, Schema, Taglibs), do not contain all of the information that is required to provide high-quality tooling support. The information that they contain simply does not have all of the information to provide semantic validation, content assistance, graphical tooling support, etc. This framework is the foundation for providing meta-data driven features used with the JSF JSP source editor in this release.

A content model can have any number of annotations files associated with it. The public id of the content model is the key. eg. "http://java.sun.com/jsf/core"

### Extension Point

The annotation file uses the extension-point `org.eclipse.jst.jsf.contentmodel.annotations.annotationFiles` to attach itself to the uri identifier of the content model.

Through the extension-point:

- The annotation file is bound to the content model using the public uri as the key
- The extender can specify it’s own reader to parse the annotation file or, if the file conforms to the `org.eclipse.jst.jsf.contentmodel.annotations.grammar-annotations` schema, the supplied default reader/parser can be used.
- An extender can specify an annotation file locator. If not specified, a plugin relative file locator is used.

An annotation file has named properties with one or more values that are given to xml elements and attributes. The file can associate 0-N named properties with any element or attribute. If there is more than one annotation file associated with the same public id and element/attribute, and there is a like-named property, it is not deterministic which property will be returned. The caller could, however, use the bundle ID of where the annotation file was created. A single plugin should not supply more than one annotation file for a given content model so that an annotation file can be identifiable.

###### eg. A Section of the JSF Core Taglibrary Annotation File

    <cm-element name="actionListener">
    	<cm-attribute name="type">
    		<property name="attribute-value-runtime-type">
    			<value>
    				org.eclipse.jst.jsf.taglibprocessing.attributevalues.JavaClassType
    			</value>
    		</property>
    		<property name="valid-interfaces">
    			<value>javax.faces.event.ActionListener</value>
    		</property>
    	</cm-attribute>
    </cm-element>
    <cm-element name="convertDateTime">
    	<cm-attribute name="dateStyle">
    		<property name="attribute-value-runtime-type">
    			<value>
    				org.eclipse.jst.jsf.taglibprocessing.attributevalues.StringType
    			</value>
    		</property>
    		<property name="valid-values">
    			<value>default</value>
    			<value>short</value>
    			<value>medium</value>
    			<value>long</value>
    			<value>full</value>
    		</property>
    		<property name="default-value">
    			<value>default</value>
    		</property>
    	</cm-attribute>
    	etc....
    </cm-element>
    etc....

### Accessing Annotations

Annotations should only be accessed thru static calls to the `CMAnnotationHelper` class. This class has many convenience methods for accessing annotations on elements and attributes. Generally, lists of CMAnnotationPropertyValues are returned for a given property name on a particular element or attribute of an element. The CMAnnotationPropertyValues class allows the caller to know where the annotation came from which allows the caller some flexibility with using or not using the meta-data.

Annotation files can be developed using wild cards to mimimize the amount of metadata that must be provided. These wild cards are supported in the sense that the caller can choose to request something other than the actual name of an element or attribute. So for example, if the attribute named "foo" applies to all elements in a content model, if "*" is used as the element name, the call to the `CMAnnotationHelper` can first look for "foo" attribute of the specifically named element, and if not found can look for the "foo" attribute on the "*" element in a second call. This gives the annotation provider greater flexibility in determining how the annotation files are structured and used. The helper will not automatically locate wild-carded annotations.

If no annotations are found by the call to `CMAnnotationHelper` for the passed parameters, methods that return:

- `List` will return an empty list and not `null`
- `String` will return `null`

For more complete information on annotations files, please see the Annotations Design Summary in CVS at /home/webtools/org.eclipse.jsf/components/jsf/developement/design/metadata .