<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.
A composite component is declared by creating a Facelets 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 Faces 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 Faces 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">
...
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.
| Info | Value |
|---|---|
| ID (tag prefix) | cc |
| URI | http://xmlns.jcp.org/jsf/composite |
| Tag | Description |
|---|---|
| actionSource |
Declares that the
composite component whose contract is declared by the
The
Most of the concepts from example content from Please see |
| 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
Please see summary page for a usage example. The top level component in which this element is
ultimately nested must be a
|
| clientBehavior |
Declares that the composite component whose contract is declared by
the |
| editableValueHolder |
Declares that the
composite component whose contract is declared by the
Please see |
| extension |
Used within a |
| facet |
Declares that this composite component supports a facet with the name given by the value of the "name" attribute. Please see |
| implementation |
Defines the implementation of the composite
component. There must be zero or one of these in a
composite component markup file. If a
|
| insertChildren |
This element is used in the
|
| insertFacet |
The presence of this tag in
a |
| 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.
For each of the behaviorial interfaces in Section JSF.3.2 of
the specification, there is a tag in the
If the Nesting of composite components The implementation must support nesting of composite
components. Specifically, it must be possible for the
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 The implementation must support any level of nesting as long as the
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 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
|
| renderFacet |
This element is used in the
The implementation of this tag handler must insert a
component with 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 |
| valueHolder |
Declares that the
composite component whose contract is declared by the
Line 2 refers to the
It is possible to declare that a single
In this case, the "targets" attribute on the
Please see |