Details
-
Type: New Feature
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 2.0-Beta2
-
Component/s: ACE-Components
-
Labels:None
-
Environment:sparkle
-
Assignee Priority:P1
Description
JSF 2 provides a new taglib.xml schema, and a new faces-config.xml schema, and comes with new files that describe the h: components and classes.
Here's how the action attribute/property is documented in each. As you can see, the faces-config documentation seems to be a superset of the taglib.xml one:
mojarra2\jsf-ri\conf\share\html_basic.taglib.xml [ taglib.xml ]
<attribute>
<description>
MethodExpression representing the application action to invoke
when this component is activated by the user. The expression
must evaluate to a public method that takes no parameters, and
returns an Object (the toString() of which is called to derive
the logical outcome) which is passed to the NavigationHandler
for this application.
</description>
<name>action</name>
<required>false</required>
<method-signature>java.lang.Object action()</method-signature>
</attribute>
mojarra2\jsf-api\doc\standard-html-renderkit.xml
<property>
<description>
MethodExpression representing the application action to invoke
when this component is activated by the user. The expression
must evaluate to a public method that takes no parameters, and
returns an Object (the toString() of which is called to derive
the logical outcome) which is passed to the NavigationHandler
for this application.
</description>
<display-name>Application Action</display-name>
<icon/>
<property-name>action</property-name>
<property-class>javax.el.MethodExpression</property-class>
<property-extension>
<method-signature>
java.lang.Object action()
</method-signature>
</property-extension>
</property>
Since the faces-config documentation provides more information than the old JSP style TLD, we should probably generate it, and find a way to create our HTML component documentation from it, hopefully using a pre-existing tool that Mojarra or MyFaces might be making use of themselves. Alternatively, we might consider generating our HTML documentation straight from our Meta classes. Lastly, we can simply shoe-horn our newer data into the TLD component description field, and continue using the existing tlddoc tool.
Here's how the action attribute/property is documented in each. As you can see, the faces-config documentation seems to be a superset of the taglib.xml one:
mojarra2\jsf-ri\conf\share\html_basic.taglib.xml [ taglib.xml ]
<attribute>
<description>
MethodExpression representing the application action to invoke
when this component is activated by the user. The expression
must evaluate to a public method that takes no parameters, and
returns an Object (the toString() of which is called to derive
the logical outcome) which is passed to the NavigationHandler
for this application.
</description>
<name>action</name>
<required>false</required>
<method-signature>java.lang.Object action()</method-signature>
</attribute>
mojarra2\jsf-api\doc\standard-html-renderkit.xml
<property>
<description>
MethodExpression representing the application action to invoke
when this component is activated by the user. The expression
must evaluate to a public method that takes no parameters, and
returns an Object (the toString() of which is called to derive
the logical outcome) which is passed to the NavigationHandler
for this application.
</description>
<display-name>Application Action</display-name>
<icon/>
<property-name>action</property-name>
<property-class>javax.el.MethodExpression</property-class>
<property-extension>
<method-signature>
java.lang.Object action()
</method-signature>
</property-extension>
</property>
Since the faces-config documentation provides more information than the old JSP style TLD, we should probably generate it, and find a way to create our HTML component documentation from it, hopefully using a pre-existing tool that Mojarra or MyFaces might be making use of themselves. Alternatively, we might consider generating our HTML documentation straight from our Meta classes. Lastly, we can simply shoe-horn our newer data into the TLD component description field, and continue using the existing tlddoc tool.
Issue Links
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion