Jakarta Server Faces 3.0.0 VDL Documentation

Tag Libraries 
LibraryDescription
f

The core JavaServer Faces custom actions that are independent of any particular RenderKit.
cc

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 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">

...

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.                      displayName="Very Simple Login Panel"
  3.                      preferred="true"
  4.                      expert="false"
  5.                      shortDescription="An illustration of the composite component feature">
  6.   <composite:attribute name="model" required="true">
  7.     <composite:attribute name="loginAction" required="true" method-signature="java.lang.Object action()"/ >
  8.   </composite:attribute>
  9.   <composite:attribute name="valueChangeListener" targets="username" />
  10.   <composite:attribute name="specialMethodExpression"
  11.                        method-signature="com.foo.User validateCurrentUser()" />
  12.   <composite:attribute name="loginButtonLabel" default="Login" />
  13.   <composite:editableValueHolder name="username" />
  14.   <composite:actionSource name="loginEvent" />
  15.   <composite:actionSource name="cancelEvent" />
  16.   <composite:actionSource name="allEvents" targets="loginEvent cancelEvent" />
  17. </composite:interface>
  18. <composite:implementation >
  19.  
  20.   <ui:decorate template="fooTemplate.xhtml">
  21.  
  22.     <ui:define name="header">
  23.  
  24.       <p>This is the login panel header</p>
  25.  
  26.     </ui:define>
  27.  
  28.     <ui:define name="body">
  29.  
  30.       <p>
  31.  
  32.          <h:inputText id="username" />
  33.  
  34.       </p>
  35.  
  36.       <p>
  37.  
  38.         <h:commandButton id="loginEvent"
  39.                          value="#{cc.attrs.loginButtonLabel}">
  40.  
  41.         </h:commandButton>
  42.  
  43.         <h:commandButton id="cancelEvent" value="Cancel" action="cancel">
  44.  
  45.         </h:commandButton>
  46.  
  47.         <special:validateUserButton
  48.           validateUser="#{cc.attrs.specialMethodExpression}" />
  49.  
  50.  
  51.       </p>
  52.  
  53.     </ui:define>
  54.  
  55.     <ui:define name="footer">
  56.  
  57.      <p>This is the login panel footer</p>
  58.  
  59.     </ui:define>
  60.  
  61.   </ui:decorate>
  62.  
  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.
p

Facelet tag attributes in this namespace must be added to the pass through attribute map
on the UIComponent corresponding to the facelet tag. There are no tags in this tag library.

Usage example

<h:outputText value="Namespaced Attributes" p:foo="bar" />

Would cause <span foo="bar">Namespaced Attributes</span> to be rendered.
jstl-fnJSTL 1.1 functions library
html_basic This tag library contains JavaServer Faces component tags for all UIComponent + HTML RenderKit Renderer combinations defined in the JavaServer Faces Specification.
ui

The tags in this library add templating — a powerful view composition technique — to Faces. Templating is so useful that there are entire frameworks, such as Tiles and SiteMesh, that are built around the concept of templating. So what is templating, how can you benefit from it, and how does this tag library implement it?

If you've used Jakarta Server Pages before, you've probably used jsp:include. The prototypical example for jsp:include is a header on each page in a web application. One Jakarta Server Pages page, say header.jsp, encapsulates the header content, and the header is included by each page. You encapsulate and reuse content, so that changes to one file, header.jsp, affect the header on every page.

This tab library contains a tag —ui:include — that's analagous to jsp:include, but encapsulating and reusing content is only half the templating story, because templating also lets you encapsulate and reuse layout. You define a single template (meaning layout), and you reuse that template with multiple compositions. So now you can control the layout of many pages with a single template (layout). Let's take a look at an example.

A Templating Example

First, we define a template:

  1. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  2.               "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  3.  
  4. <html xmlns="http://www.w3.org/1999/xhtml"
  5.             xmlns:ui="http://xmlns.jcp.org/jsf/facelets"
  6.     <head>
  7.       <link href="styles.css" rel="stylesheet" type="text/css"/>
  8.       <title><ui:insert name="title">Default Title</ui:insert></title>
  9.     </head>
  10.  
  11.     <body>
  12.       <ui:debug/>
  13.       <div class="heading">
  14.         <ui:insert name="heading"/>
  15.       </div>
  16.  
  17.       <div class="content">
  18.         <ui:insert name="content"/>
  19.       </div>
  20.     </body>
  21. </html>

In the preceeding listing, we've defined a layout, also known as a template. That template uses the ui:insert tag to insert pieces of a page — namely, title, heading, and content — defined in a composition. Notice that on line 8, we define a default title, in case one isn't provided by the composition. Also note that on line 12 we have the ui:debug tag, which lets the user activate a popup window with debugging information by typing CTRL + Shift + d.

The title, heading, and content pieces of the page referenced in the template are defined in a separate XHTML file in a composition, like this:

  1. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  2.         "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  3.  
  4. <html xmlns="http://www.w3.org/1999/xhtml"
  5.    xmlns:ui="http://xmlns.jcp.org/jsf/facelets">
  6.  
  7.   <body>
  8.     <ui:composition template="/layout.xhtml">
  9.  
  10.       <ui:define name="title">A List of Contacts</ui:define>
  11.       <ui:define name="heading">Contacts</ui:define>
  12.  
  13.       <ui:define name="content">
  14.         <ui:include src="contactsTable.xhtml" />
  15.       </ui:define>
  16.          
  17.     </ui:composition>
  18.   </body>
  19. </html>

At runtime, Faces synthesizes the two previous XHTML pages to create a single Faces view by inserting the pieces defined in the composition into the template (that template is layout.xhtml, which is the first listing above). Faces also disregards everything outside of the composition tag so that we don't wind up with two body elements in the view. Also, note that we use the ui:include tag on line 14 to include content (which happens to be a table) from another XHTML page, so that we can reuse that table in other views.

So why do we have two XHTML pages to define a single view? Why not simply take the pieces and manually insert them into the layout so that we have only a single XHTML page? The answer is simple: we have separated layout from the content so that we can reuse that layout among multiple compositions. For example, now we can define another composition that uses the same layout:

  1. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  2.         "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  3.  
  4. <html xmlns="http://www.w3.org/1999/xhtml"
  5.       xmlns:ui="http://xmlns.jcp.org/jsf/facelets">
  6.  
  7.   <body>
  8.     <ui:composition template="/layout.xhtml">
  9.  
  10.       <ui:define name="title">Create a Contact</ui:define>
  11.       <ui:define name="heading">Create Contact</ui:define>
  12.  
  13.       <ui:define name="content">
  14.         <ui:include src="createContactForm.xhtml"/>
  15.       </ui:define>
  16.  
  17.     </ui:composition>
  18.   </body>
  19. </html>

By encapsulating the layout, we can reuse that layout among multiple compositions. Just like ui:include lets us encapsulate and reuse conent, Faces compositions let us encapsulate and reuse layout, so that changes to a single layout can affect multiple views. Fundamentally, that's what this tag library is all about.
jsf

The presence of an
attribute from this namespace on an otherwise non-Faces aware
markup element indicates that the markup element must be treated
as a Faces component that will be rendered equivalently to what is
specified directly in the Facelet page, with the added benefit
of being associated with a server side UIComponent
instance.

Please see the documentation for Java class jakarta.faces.view.facelets.TagDecorator.
jstl-core

JSTL 1.2 core library

The pre Faces version of Facelets incorrectly declared the taglib uri to be http://xmlns.jcp.org/jstl/core. For backwards compatibility implementations must correctly handle inclusions with the incorrect uri, and the correct uri, declared here.