Overview    Library   Tag   Help 
 FRAMES   NO FRAMES 

Composite Components

Standard Syntax:
     <%@ taglib prefix="cc" uri="http://xmlns.jcp.org/jsf/composite" %>
XML Syntax:
     <anyxmlelement xmlns:cc="http://xmlns.jcp.org/jsf/composite" />
 
 
 
Describes the Facelets2 tag library used for declaring and defining the usage contract for composite UI Components. When authoring a composite component, use of this tag library is largely optional, though always recommended. Declaring and defining a composite component with this taglib provides valuable information about the component that can be used by tools and users of the composite component. In most cases, a composite component can be authored without declaring and defining its usage contract with this taglib. 
  
Creating a Composite Component
 
A composite component is declared by creating a Facelets2 file inside of a resource library. (See section JSF.2.6 of the specification prose document for more information about resource libraries.) A composite component must reside within a resource library. It is not possible to create a composite component without putting it inside of a resource library.
 
The default XML namespace URI of the taglib that contains the composite component, for use in the using page, is http://xmlns.jcp.org/jsf/composite/<composite-library-name>, where <composite-library-name> is the name of the resource library. For example:
 
 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml"
 xmlns:h="http://xmlns.jcp.org/jsf/html"
 xmlns:f="http://xmlns.jcp.org/jsf/core"
 xmlns:ui="http://xmlns.jcp.org/jsf/facelets"
 xmlns:ez="http://xmlns.jcp.org/jsf/composite/ezcomp">
 ...
 
 
This declares that any Facelets2 file in the resource library called ezcomp can be used as a regular JSF UI component in a view with the above namespace declaration by using the "ez" prefix. For example, placing a file called foo.xhtml in a resource library called ezcomp would make that file accessible like this.
 
 <ez:foo /> 
 
The implementation must also support declaring the namespace of the tag library in a JSF VDL tag library descriptor. This descriptor file is optional and is useful for component vendors that do not want to use the default XML namespace. This version of the proposal currently uses the facelet taglib descriptor syntax. For example: 
 
 <facelet-taglib>
 <namespace>http://domain.com/path</namespace> 
 <composite-library-name>compositeTest</composite-library-name> 
 </facelet-taglib> 
 
 
Components from that taglibrary may be used in a using page by declaring them in the XML namespace for that view:
 
 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml"
 xmlns:h="http://xmlns.jcp.org/jsf/html"
 xmlns:f="http://xmlns.jcp.org/jsf/core"
 xmlns:ui="http://xmlns.jcp.org/jsf/facelets"
 xmlns:ez="http://domain.com/path/namespace">
 ...
 
 
Below is an example of a fairly involved composite component declaration. Such a declaration might appear in foo.xhtml.
 
  1. <composite:interface name="foo"
    2.  
  2.                      displayName="Very Simple Login Panel"
    3.  
  3.                      preferred="true"
    4.  
  4.                      expert="false"
    5.  
  5.                      shortDescription="An illustration of the composite component feature">
    6.  
  6.   <composite:attribute name="model" required="true">
    7.  
  7.     <composite:attribute name="loginAction" required="true" method-signature="java.lang.Object action()"/ >
    8.  
  8.   </composite:attribute>
    9.  
  9.   <composite:attribute name="valueChangeListener" targets="username" />
    10.  
  10.   <composite:attribute name="specialMethodExpression"
    11.  
  11.                        method-signature="com.foo.User validateCurrentUser()" />
    12.  
  12.   <composite:attribute name="loginButtonLabel" default="Login" />
    13.  
  13.   <composite:editableValueHolder name="username" />
    14.  
  14.   <composite:actionSource name="loginEvent" />
    15.  
  15.   <composite:actionSource name="cancelEvent" />
    16.  
  16.   <composite:actionSource name="allEvents" targets="loginEvent cancelEvent" />
    17.  
  17. </composite:interface>
    18.  
  18. <composite:implementation >
    19.  
  19.  
    20.  
  20.   <ui:decorate template="fooTemplate.xhtml">
    21.  
  21.  
    22.  
  22.     <ui:define name="header">
    23.  
  23.  
    24.  
  24.       <p>This is the login panel header</p>
    25.  
  25.  
    26.  
  26.     </ui:define>
    27.  
  27.  
    28.  
  28.     <ui:define name="body">
    29.  
  29.  
    30.  
  30.       <p>
    31.  
  31.  
    32.  
  32.          <h:inputText id="username" />
    33.  
  33.  
    34.  
  34.       </p>
    35.  
  35.  
    36.  
  36.       <p>
    37.  
  37.  
    38.  
  38.         <h:commandButton id="loginEvent" 
    39.  
  39.                          value="#{cc.attrs.loginButtonLabel}">
    40.  
  40.  
    41.  
  41.         </h:commandButton>
    42.  
  42.  
    43.  
  43.         <h:commandButton id="cancelEvent" value="Cancel" action="cancel">
    44.  
  44.  
    45.  
  45.         </h:commandButton>
    46.  
  46.  
    47.  
  47.         <special:validateUserButton 
    48.  
  48.           validateUser="#{cc.attrs.specialMethodExpression}" />
    49.  
  49.  
    50.  
  50.  
    51.  
  51.       </p>
    52.  
  52.  
    53.  
  53.     </ui:define>
    54.  
  54.  
    55.  
  55.     <ui:define name="footer">
    56.  
  56.  
    57.  
  57.      <p>This is the login panel footer</p>
    58.  
  58.  
    59.  
  59.     </ui:define>
    60.  
  60.  
    61.  
  61.   </ui:decorate>
    62.  
  62.  
    63.  
  63. </composite:implementation> 
 
The values for attributes in a composite component VDL file can be fully localized by putting them inside a ResourceBundle in the same directory as the VDL view and accessing them with the per-component resource bundle syntax. Consider the file foo.xhtml, in the resource library ezcomp. The shortDescription element could be changed to be:
 
 <composite:interface shortDescription="#{cc.resourceBundleMap.shortDescription}" > 
 
In this case, In the same ezcomp directory as foo.xhtml, there would be a foo.properties file that would contain this entry:
 
 shortDescription=A really nifty login panel. 
 
The normal localization rules for ResourceBundle would apply.
 
Refer to the composite tag for the details of defining the interface and implementation for composite components.
 
 







Tag Library Information




Display NameComposite Components




Version2.1




Short Namecc




URIhttp://xmlns.jcp.org/jsf/composite




             
            





Tag Summary




actionSource
 
Declares that the composite component whose contract is declared by the <composite:interface> in which this element is nested exposes an implementation of ActionSource2 suitable for use as the target of attached objects in the using page. Any attached objects suitable for implementations of ActionSource2 may be attached to the composite component. Consider this excerpt from the using page: 
 
  1. <ez:loginPanel id="loginPanel" model="#{bean}">
    2.  
  2.   <f:valueChangeListener for="username"
    3.  
  3.                              binding="#{bean.useridValueChangeListener}" />
    4.  
  4.   <f:actionListener for="loginEvent" 
    5.  
  5.                     binding="#{bean.loginEventListener}" />
    6.  
  6.  
    7.  
  7.   <f:actionListener for="cancelEvent" 
    8.  
  8.                     binding="#{bean.cancelEventListener}" />
    9.  
  9.  
    10.  
  10.   <f:actionListener for="allEvents" 
    11.  
  11.                     binding="#{bean.allEventsListener}" />
    12.  
  12.  
    13.  
  13. </ez:loginPanel> 
 
The <f:actionListener> elements on lines 4, 7, and 10 refer to the attached objects declared on lines 2, 3 and 4 below.
 
  1. <composite:interface name="loginPanel">
    2.  
  2.   <composite:actionSource name="loginEvent" />
    3.  
  3.   <composite:actionSource name="cancelEvent" />
    4.  
  4.   <composite:actionSource name="allEvents" targets="loginEvent cancelEvent" />
    5.  
  5. </composite:interface> 
 
Most of the concepts from example content from <composite:valueHolder> also applies in the case of <composite:actionSource>.
 
Please see <composite:interface> for a usage example.
 





attribute
 
Declares an attribute that may be given to an instance of the composite component tag for this composite component. There may be zero or many of these inside of the <composite:interface> section. This element may be nested within other <composite:attribute> elements to convey a usage contract that includes nested properties.
 
Please see summary page for a usage example.
 
The top level component in which this element is ultimately nested must be a NamingContainer. There are certain component properties that must not be exposed using this element. The motivation for this restriction is that the mapping of markup attributes to component properties/attributes does not allow for these attributes to be set. The following properties must not be exposed using this element.
 
     
  • binding
    •  
  • id
    •  
  • inView
    •  
  • parent
    •  
  • rendered
    •  
  • rendererType
    •  
  • transient
    •  
 





clientBehavior
 
Declares that the composite component whose contract is declared by the <composite:interface> in which this element is nested exposes an implementation of ClientBehaviorHolder suitable for use as the target of attached objects in the using page. Any attached objects suitable for implementations of ClientBehaviorHolder may be attached to the composite component.
 





editableValueHolder
 
Declares that the composite component whose contract is declared by the <composite:interface> in which this element is nested exposes an implementation of EditableValueHolder suitable for use as the target of attached objects in the using page. Any attached objects suitable for implementations of EditableValueHolder may be attached to the composite component.The example from <composite:valueHolder> still applies. 
 
Please see <composite:interface> for a usage example.
 





extension
 
Used within a <composite:interface> section, within any sub-element of that section, to include XML content not defined by this specification. This element can be used to incorporate JSR-276 metadata into a composite component.
 





facet
 
Declares that this composite component supports a facet with the name given by the value of the "name" attribute. 
 
Please see <composite:interface> for a usage example.
 





implementation
 
Defines the implementation of the composite component. There must be zero or one of these in a composite component markup file. If a <composite:interface> element appears, there must be a corresponding <composite-implementation> element. If no <composite:interface> element appears, the <composite-implementation> element is optional. 
 





insertChildren
 
This element is used in the <composite:implementation> section. Any child components and/or template text within the composite component tag in the using page will be re-parented into the composite component at the point indicated by this tag's placement within the <composite:implementation> section. The normal use-case for this element is to have exactly one occurrence within the <composite:implementation> section. Inserting multiple occurrences may cause duplicate id errors. The results are undefined if there are multiple occurrences of this element in the <composite:implementation> section. The results are undefined if there are child components and/or template text in the composite component tag in the using page, but there is no occurrence of this element in the <composite:implementation> section.
 





insertFacet
 
The presence of this tag in a <composite:implementation> section must cause the named facet to be taken from the facet map of the top level component and inserted as a facet child of the component in which this element is nested. The results are undefined if there are facets in the composite component tag in the using page, but there is no correspondingly named occurrence of this element in the <composite:implementation> section.
 





interface
 
This element declares the usage contract for a composite component. Optionally, and at the component author's discretion, this contract exposes the features of one or more inner components to the page author. The page author can work with the composite component as a single component whose feature set is the union of the features declared in the usage contract.
 
For example, consider a composite component that implements the functionality of a "login panel". Such a component would likely have two text fields and one button. The user of such a component might like to do one or more of the following.
 
     
  • Be able to listen for the ActionEvent on the button.
     
    In this case, a <composite:actionSource> element is included in the usage contract that refers to the inner button in the <composite:implementation> section.
     
    •  
  • Provide an "action" to invoke when the button is pressed. 
     
    In this case, a <composite:attribute> element is included in the usage contract that refers to the inner button in the <composite:implementation> section and declares the proper method signature for an "action".
     
    •  
  • Provide parameters to the composite component for labels and other rendering specific aspects of the composite component.
     
    In this case, one or more <composite:attribute> elements are included in the usage contract and those parameters are referred to in the <composite:implementation> section using EL expressions like #{cc.attrs.usernameLabel}, assuming usernameLabel is the name of one of the <composite:attribute> elements in the usage contract.
     
    •  
  • Add ValueChangeListeners, Converters, or Validators to either or both text fields. 
     
    In this case, a <composite:editableValueHolder> element is included in the usage contract that refers to the inner text field in the <composite:implementation> section. In the case of wanting to enable only adding a Converter (and not a ValueChangeListener or Validator, a <composite:valueHolder> element would be used.
     
    •  
  • Add facet children to the login panel.
     
    In this case, a <composite:facet> element is included in the usage contract that refers to the inner <composite:renderFacet> element in the <composite:implementation> section. 
     
    •  
 
For each of the behaviorial interfaces in Section JSF.3.2 of the specification, there is a tag in the composite: library to nest inside of the <composite:interface> section. 
 
If the <composite:interface> section is not present in a VDL view, the contract will be inferred as described in the specification. There must be zero or one of these elements in a composite component VDL file. If a <composite:interface> element does appear, there must be an accompanying <composite:implementation> element in the same VDL file. 
 
Nesting of composite components
 
The implementation must support nesting of composite components. Specifically, it must be possible for the <composite:implementation> section of a composite component to act as the using page for another composite component. When a composite component exposes a behavioral interface to the using page, such as a <composite:actionSource>, <composite:editableValueHolder>, <composite:valueHolder> or other behavioral interface, it must be possible to “propogate” the exposure of such an interface in the case of a nested composite component. The composite component author must ensure that the value of the name attributes exactly match at all levels of the nesting to enable this exposure to work. The implementation is not required to support “re-mapping” of names in a nested composite component.
 
For example, consider this nested composite component.
 
Using page
 
  1. <ez:actionSourceOuter>
    2.  
  2.   <f:actionListener for="button1" />
    3.  
  3. </ez:actionSourceOuter> 
 
actionSourceOuter.xhtml: Outer composite component
 
  1. <composite:interface>
    2.  
  2.   <composite:actionSource name="button1" />
    3.  
  3. </composite:interface>
    4.  
  4.  
    5.  
  5. <composite:implementation>
    6.  
  6.   <ez:actionSourceInner />
    7.  
  7. </composite:implementation> 
 
actionSourceInner.xhtml: the composite component used within a composite component.
 
  1. <composite:interface>
    2.  
  2.   <composite:actionSource name="button1" />
    3.  
  3. </composite:interface>
    4.  
  4.  
    5.  
  5. <composite:implementation>
    6.  
  6.   <h:commandButton id="button1" value="the real button" />
    7.  
  7. </composite:implementation> 
 
The id of the <h:commandButton> on line 6 of actionSourceInner.xhtml must match the name on line 2 of that file (this is a standard requirement for all composite components, nested or not). That id must also match the name on line 2 of actionSourceOuter.xhtml, and the for on line 2 of the using page.
 
The implementation must support any level of nesting as long as the for, name, and id values match up. Furthermore, the targets attribute is also valid for use in this nested fashion.
 
Naming containers within composite components
 
Composite components are themselves naming containers so that any possible id conflicts between inner components and components in the using page are avoided. However, special care must be taken when using naming containers in the <composite:implementation> section. In such cases the value of the “name” attribute, or the values of the “targets” attribute must be used with a clientId relative to the top level component to expose any attached object targets to the using page. For example:
 
Using page
 
  1. <ez:loginButton>
    2.  
  2.   <f:actionListener for="button" binding="#{foo.actionListener}" />
    3.  
  3. </ez:loginButton> 
 
loginButton.xhtml
 
  1. <composite:interface>
    2.  
  2.   <composite:actionSource name="button" targets="form:button" />
    3.  
  3. </composite:interface>
    4.  
  4.  
    5.  
  5. <composite:implementation>
    6.  
  6.  
    7.  
  7.   <h:form id="form">
    8.  
  8.     <h:commandButton id="button" value="Submit" />
    9.  
  9.   </h:form>
    10.  
  10. </composite:implementation> 
 
Because the button on line 8 resides within a form, it must be referred to using a client id, relative to the top level component, in the "targets" attribute on line 2. Using a relative clientId is required due to the semantics of UIComponent.findComponent().
 





renderFacet
 
This element is used in the <composite:implementation> section. The facet with the name equal to the value of the name attribute, given by the page author in the using page, will be rendered at this point in the composite component VDL view. 
 
The implementation of this tag handler must insert a component with component-type javax.faces.Output and renderer-type javax.faces.CompositeFacet as a child at this point in the component tree.
 
The implementation of this tag handler must store an attribute into the created component's attribute map under the key given by the value of the symbolic constant UIComponent.FACETS_KEY. The value for this key must be the evaluated value of the "name" attribute.
 





valueHolder
 
Declares that the composite component whose contract is declared by the <composite:interface> in which this element is nested exposes an implementation of ValueHolder suitable for use as the target of attached objects in the using page. Any attached objects suitable for implementations of ValueHolder may be attached to the composite component. Consider this excerpt from the using page: 
 
  1. <ez:foo>
    2.  
  2.   <f:converter for="userid" binding="#{bean.converter}" />
    3.  
  3. </ez:foo> 
 
Line 2 refers to the <composite:valueHolder> declaration on line 2 of foo.xhtml:
 
  1. <composite:interface>
    2.  
  2.   <composite:valueHolder name="userid" />
    3.  
  3. </composite:interface>
    4.  
  4.  
    5.  
  5. <composite:implementation>
    6.  
  6.   <h:inputText id="userid" />
    7.  
  7. </composite:implementation> 
 
 
It is possible to declare that a single <composite:valueHolder> element should cause multiple components within the <composite:implementation> section to be the targets of an attached object in the using page. Assuming the same using page excerpt as above, the revised VDL view is:
 
  1. <composite:interface>
    2.  
  2.   <composite:valueHolder name="inputs" targets="userid,password" />
    3.  
  3. </composite:interface>
    4.  
  4.  
    5.  
  5. <composite:implementation>
    6.  
  6.   <h:inputText id="userid" />
    7.  
  7.   <h:inputText id="password" />
    8.  
  8. </composite:implementation> 
 
In this case, the "targets" attribute on the <composite:valueHolder> element, on line 2 above, replaces the "name" attribute in the previous example. "targets" is a list of ids of client ids (relative to the top level component) within the <composite:implementation> section. In this case, "targets" refers to the <h:inputText> components on lines 6 and 7 above.
 
Please see <composite:interface> for a usage example.
 





               
              











     Overview       Library   Tag      Help 










                 FRAMES 
                 NO FRAMES