Extend facelet-taglib schema

[eclipse-faces-bot]

The Facelet taglib XML file has a number of limitations and it might be a good idea to improve the format.

Currently when a component inherits from another component, each and every attribute of the parent component has to be copied into the tag declaration in the taglib file. This makes taglib files very verbose and makes it hard to see which attribute the new tag introduces. A solution to this would be adding a way to declare that a tag inherits from another tag.

For instance:

<tag extends-namespace="http://java.sun.com/jsf/html" extends-tag="form">
    <tag-name>form</tag-name>
    <component>
        <component-type>org.example.Form</component-type>
    </component>

    <attribute>
        <description>
            Whether to include all URL (GET) request parameters in the action URI.
        </description>
        <name>includeRequestParams</name>
        <required>false</required>
        <type>boolean</type>
    </attribute>

    <!-- 20+ attributes of h:form such as "render", "accept", etc inherited -->
</tag>

Components in JSF can introduce an (EL) variable for their children to consume, e.g. like the var attribute of a datatable. This can however not be declared in a taglib, so tools have to have hardcoded knowledge of which tag does what with which attribute. This means tools lack behind new tags from a certain component library and only well known component libraries are supported. It would be great if it could be declared that an attribute represents the name of an introduced (EL) variable.

For instance:

<attribute>
    <description>
        Name of a request-scope attribute under which the model data for the
        row selected by the current value of the "rowIndex" property
        (i.e. also the current value of the "rowData" property) will be exposed.
    </description>
    <name>var</name>
    <required>false</required>
    <type>java.lang.String</type>
    <output>
        <scope>request</scope>
        <type-ref-attribute>value</type-ref-attribute>
        <type-ref-collection-element>true</type-ref-collection-element>
    </output>
</attribute>

In the above example var is declared to be an "output variable", that has as its type the type of the "collection element" that's bound to the value attribute. E.g. if value is bound to a List, then the type of var is Foo. Other options would be setting a fixed type or referring directly to the type of another attribute.

Another issue is that attributes often have a default and an allowed range of values. This now has to be communicated in the description of an attribute and that description has to be kept in sync with the actual code. Tools sometimes have hardcoded knowledge of the allowed values (for auto-completion and warning flagging) for some attribute, but this too can be out of sync with newer releases of a component lib and doesn't support lesser known or internal components.

It would help a lot of this could be declared in a taglib file as well. E.g.:

<attribute>
    <description>The ordering type.</description>
    <name>type</name>
    <required>false</required>
    <type>java.lang.String</type>
    <allowed-values>lt, lte, gt, gte</allowed-values>
    <default>lt</default>
</attribute>

Some JSF components, like e.g. datatable support multiple types for a given attribute. It might be an improvement if these types could be enumerated in the attribute's declaration, e.g.

<attribute>
    <description>
        The current value of this component.
    </description>
    <name>value</name>
    <required>false</required>
    <types>
        <type>javax.faces.model.DataModel</type>
        <type>java.util.List</type>
        <type>java.lang.Object[]</type>
        <type>java.sql.ResultSet</type>
        <type>javax.servlet.jsp.jstl.sql.Result</type>
        <type>java.util.Collection</type>
        <type>java.lang.Object </type>
    <types>
</attribute>

I'm sure there might be some other areas where taglib files can be improved besides the use cases mentioned above.

[eclipse-faces-bot]

• Issue Imported From: https://github.com/javaee/javaserverfaces-spec/issues/1190
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: Unassigned

[eclipse-faces-bot]

@glassfishrobot Commented Reported by @arjantijms

[eclipse-faces-bot]

@glassfishrobot Commented @edburns said: Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

[eclipse-faces-bot]

@glassfishrobot Commented This issue was imported from java.net JIRA JAVASERVERFACES_SPEC_PUBLIC-1190