cc

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

actionSourceOuter.xhtml: Outer composite component

actionSourceInner.xhtml: the composite component used within a composite component.

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

loginButton.xhtml

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().