JavaServer Faces vs Tapestry - A Head-to-Head Comparison

JSF

JSF uses JSPs as its primary display technology. Standard compliant JSF implementations must implement a set of proscribed JSP tags to represent the core components. The JSP tags bear less than a passing resemblance to HTML. Here's an example of an HTML form using JSF component tags:

<h:form>      
  <h:panelGrid columns="2" border = "1">
        <h:outputText styleClass = "label" value="No"/>

        <h:outputText value="#{holidaySession.currentHolidayBooking.holidayID}"/>
        <h:outputText styleClass = "label" value="Date"/>
        <h:outputText value="#{holidaySession.currentHolidayBooking.date}"/>

        <h:outputText styleClass = "label" value="Number of days"/>
        <h:outputText value="#{holidaySession.currentHolidayBooking.amount.value}"/>
        <h:outputText styleClass = "label" value="Description"/>

        <h:outputText value="#{holidaySession.currentHolidayBooking.description}"/>
 </h:panelGrid>
 <BR>
 <h:commandButton value="Back" action="#{holidaydetail_backing.home}" immediate = "true"/>

</h:form>
  

JSP is the primary view technology for JSF, but not the only one. An interesting alternative is described in Hans Bergsten's article, Improving JSF by Dumping JSP. Bergsten's article also describes some serious anomalies arising from mixing JSF and JSP tags. These are being fixed through a combination of specification changes in JSF 1.2 and enhancements to the JSP 2.1 expression language.

Tapestry

For most applications, Tapestry templates are simply regular HTML, decorated with Tapestry attributes. Here's an example:

<span jwcid = "@Conditional" condition = "ognl:currentHolidayBooking">  
        <p><strong>Holiday Details</strong></p>
        <table>
        <tr>
                <td class = "label">No</td>
                <td><span jwcid = "@Insert" 
                        value = "ognl:currentHolidayBooking.holidayID">1</span>
                </td>
        </tr>
        <tr>                      
            <td class = "label">Start date</td>
                <td><span jwcid = "@Insert" 
                        value = "ognl:currentHolidayBooking.date" format = "ognl:dateFormat">1</span>
                </td>
        </tr>
        <tr>                               
            <td class = "label">Number of days</td>
                <td><span jwcid = "@Insert" 
                        value = "ognl:currentHolidayBooking.amount.value">1</span>
                </td>
        </tr> 
        <tr>               
            <td class = "label">Description</td>    
                <td><span jwcid = "@Insert" 
                        value = "ognl:currentHolidayBooking.description">1</span>
                </td>
        </tr>
        </table>
</span>

The jwcid = "@componentName" attribute identifies the tag as a Tapestry tag.

Tapestry templates don't need to be HTML. Tapestry supports any markup, provided that the Tapestry tags themselves are well-formed XML, in the sense that the opening tag must be well-formed and have a corresponding well-formed closing tag. Tapestry templates are implemented in the markup language of their target environment, which would typically be HTML or WML for wireless applications. Tapestry templates can be previewed without being deployed onto a Servlet container.

Tapestry

Each page screen in your Tapestry application typically consists of a page template (usually HTML), a Java class with properties and methods, and a page specification file used to define how template controls are bound to Java classes. There are variations around this. Tapestry has a specific mechanism for accessing HttpSession- or ServletContext-bound state; it is possible to do so directly from within a template or page specification.

Also it is possible to have a skeletal page specification with all data binding defined in the template itself. It is not possible, however, to bind display controls to instances of arbitrary classes with request scope. Request scope bindings must be to properties and methods accessible through a specific page class. The main restriction regarding the page class implementation is that it needs to subclass BasePage or AbstractPage. In other words, the classes in which you write your presentation logic inherit a lot of dependencies which ideally should be internal to the framework. Future versions of Tapestry should remove these restrictions and allow for a less coupled programming model.

JSF

In JSF there is no page specification file. Instead, there is a global configuration file, called faces-config.xml, in which as set of "managed beans" are defined. Managed beans are regular JavaBeans with properties and event listeners. Each backing bean is identified in faces-config.xml by three items of information: a String identifier, a Java class name, and a scope for the bean, which may be request, session or application. Once defined in faces-config.xml, a display control on any JSF template can reference the backing bean using the identifier. Managed beans can be configured to reference other managed beans.

JSF

JSF's life cycle is implemented in a very clearly defined six step process: Restore View, Apply Request Values, Process Validations, Update Model Values, Invoke Application and Render Response. At each point after the second of the six stages - Apply Request Values - it is possible to short-circuit the process and move directly to the Render Response phase, or even to output a response directly and notify the JSF runtime that response handling is complete. Any method with access to the JSF FacesContext object, including phase listeners, event handlers, converters and validators can short-circuit the normal request handling life cycle.

Tapestry

While JSF consists of a single life cycle model, the Tapestry life cycle depends on the engine service being invoked. This is because each engine service has its own life cycle. For example, the Direct Service handles form submissions, while the Page Service can be used to simply render a page without any additional server side processing. Each engine service has a life cycle which is designed to suit the task it is trying to accomplish. For very specialized requirements, it is possible to create your own engine service with a customized life cycle.

Tapestry

When a user interacts with a Tapestry view, for example by clicking a link or submitting a form, a listener method on the server is invoked. The listener method contains logic to determine whether to navigate to a different page, and which page to navigate to. Navigation logic is defined in code, rather than in a configuration file. Navigating between pages is simply a case of activating the required page, using the IRequestCycle.activate() method. The example below shows how this is done.

Lets consider how it works with our example holiday booking application.

The home page contains the following code

<input jwcid = "new@Submit" listener = "ognl:listeners.newSubmit" name="new_submit" type="submit" value="New" />

The newSubmit() method in the page class handles the transfer by calling the IRequestCycle's activate() method.

public void newSubmit(IRequestCycle cycle)
{
        cycle.activate("NewHoliday");
}

This mechanism can be used for simple page navigation (using the DirectLink component) as well as form submission. Tapestry also provides alternatives which do not involve posting back to the current form. The ExternalLink component can be used to navigate directly to another page in the application. Here, the target page needs to implement the IExternalPage interface.

Application-specific parameter values can be encoded into the URL, and received by the target page as an array of Objects (rather than String name value pairs). But this means that your activateExternalPage() implementation needs to read the encoded parameters in the correct order.

As long as the target page does not rely on HttpSession state, the ExternalLink URL can be used to bookmark pages. But the format is far from user friendly: here's an example: http://localhost:8080/tapestry/app?service=external/HolidayDetails&sp=4. Tapestry 4.0 will allow for much more user-friendly URLs, at the price of extra configuration effort.

Tapestry supports redirects in a rather clumsy way by allowing you to throw a RedirectException. It requires some effort to implement the Redirect After Post pattern in Tapestry. One approach is to use a "redirect" page which in turn passes parameters to a target page using the ExternalLink mechanism.

JSF

In JSF, you need to use a combination of code and configuration to transfer control to a different page after posting a form. Here's what's required:

• your form control (HtmlCommandButton or HtmlCommandLink) must be bound to a managed bean action event handler. The event handler must have the form
  
  public String actionName();
  
  You may initially get confused between action event handlers and action listeners. The latter has the signature
  
  public void actionListenerName(FacesContext context);
  
  and cannot effect navigation

• the String value returned from the action method must correspond to an entry in the faces-config.xml, which maps this value to a subsequent view. Here's an example from the JSF version of our holiday booking application:

  <navigation-rule>
          <from-view-id>/home.jsp</from-view-id>
          <navigation-case>
                  <from-outcome>newHoliday</from-outcome>
                  <to-view-id>/newholiday.jsp</to-view-id>
          </navigation-case>
          <navigation-case>
                  <from-outcome>detail</from-outcome>
                  <to-view-id>/holidaydetail.jsp</to-view-id>
          </navigation-case>
          <navigation-case>
                  <from-outcome>delete</from-outcome>
                  <to-view-id>/home.jsp</to-view-id>
          </navigation-case>
  </navigation-rule>

  You can specify navigation as a redirect rather than forward.

  Struts users will no doubt recognize the navigation-rule mechanism. Because these rules are centrally located in an XML document, it's fairly straightforward to visually represent and manipulate these using a tool.

• As a shortcut, you can also put the navigation action straight into the page, as in <h:commandButton value="next" action="next" />

With JSF you also have an alternative mechanism for simple page links within the application. The HtmlOutputLink can be used instead of the HtmlCommandLink. Parameters are encoded as HttpServletRequest parameters. They can be retrieved from the target page as Strings via the FacesContext object. In this case, you still need to handle the String to object conversions yourself, something which you can avoid when working with Tapestry's ExternalLink.

JSF

JSF event model was designed to be similar to the JavaBeans event model. The main JSF event handlers are the action methods and the action listeners, both introduced in the previous section. Note that it is possible and sometimes necessary to define both an action listener and an action method for a component instance. This is because action listeners cannot influence navigation, while action events have no access to information on the component generating the event. Some users may find this distinction a bit confusing or even contrived.

JSF also has value change events, which allow for automatic resubmission of forms when input values are modified. There is no equivalent in the current version of Tapestry.

Tapestry

In the previous section we saw an example of the Tapestry workhorse event handler, which for Tapestry 3.0 are page class methods with the signature

public void methodName(IRequestCycle cycle);
  

An advantage of Tapestry page classes is that event handling can be tied specifically to different stages of the page loading and rendering process. Methods your page class can implement include:

• public void pageBeginRender(PageEvent event): allows page state to be configured before rendering occurs, for example, by reading data from a database
• public void pageValidate(PageEvent event): allows the page to be validated, for example, by checking that the current user is authenticated
• public void pageDetached(PageEvent event): allows for release of resources used during the request

Tapestry

Tapestry aims for an efficient component state management mechanism by minimizing the number of times a page's component tree is loaded. When a page is requested for the first time, an instance of the page class, together with instances of all its contained components, is created. When the request has been serviced, the page instance is added to an object pool. Subsequent requests can reuse this page instance, returning it to the pool when finished. New instances of the same page will only be created if no page instance is available in the pool when the request arrives.

What makes this possible is that a Tapestry component tree is static. It cannot be modified programmatically at runtime. Whether a component displays (conditional evaluation) and how many times it displays (iteration) depend entirely on data supplied to a component. For example, the number of items displayed by a Foreach component depends on the size of the Collection passed in as an input to the component.

The downside of Tapestry's data-centric approach is that it introduces a few subtle issues into the way that form submission is handled. Tapestry has no equivalent of the Restore View phase. To recover values obtained from form submission, it re-renders the same form, populating component properties and applying data bindings in the process. However, if the model data used to re-render the form changes, the rewound form is no longer in sync with the submitted data, resulting in a StaleLinkException. This issue is probably the number one pitfall for novice Tapestry users, and surely the number one cause for complaint on the Tapestry users' mailing list. Tapestry 4.0, however, provides at least a partial solution to the problem in the form of the For and If components, which store data used for rendering in hidden fields, allowing this same data to be used to rewind the form during postback.

JSF

JSF does not specifiy exactly how component state should be managed, leaving this as an implementation detail for the view handler. The default view handlers of both MyFaces and JSF RI, however, work in a similar way. When a page is rendered, the component tree for the view being rendered is built on the fly. The application can be configured to use client or server-based component state management. If server based state management is used, the view is saved in user's session as a serialized object. This happens when the View component's JSP tag handler is executed.

When data is posted, the same set of components need to be reconstructed as were originally rendered. This is to allow the components' state to be updated with the user-supplied values, which in turn need to be converted to the correct types and validated. The component tree is reconstructed during the Restore View phase, either from serialized HttpSession data, or from a serialized object passed in from the client. MyFaces currently only holds the last view in the session, while by default the JSF RI will hold up to 15 serialized views in the session.

Tapestry

Tapestry provide an impressive set of standard components, covering all the main HTML controls, links, as well as components for iteration and conditional inclusion of template content. With core components alone it's possible to create fairly sophisticated form-based applications which include file uploads, rollovers, calendar-based date selection, etc. Tapestry also provides a number of other "contributed" components which are not core framework components, but are still part of the official distribution, for more advanced or specialized application requirements.

JSF

The standard JSF components cover all the standard HTML controls. However, there are some fairly basic omissions. There is also no explicit iteration or conditional logic handling components. Working around the latter is fairly straightforward in that every component includes an rendered property which determines whether the component is visible.

The absence of iteration is more problematic. One workaround is to use the HtmlDataGrid component, which allows for tabular output of dynamic data. But there are limitations in the way that HtmlDataGrid can be used with other components. For example it is not possible to dynamically create a set of radio buttons, with each radio button linked to a row on the HtmlDataGrid output. In other words, a form such as the Tapestry holiday booking home page cannot be rendered using standard JSF components. Instead, we need to use links within each row of the form, as shown below:

It's also not currently possible to use JSF tags within JSTL iteration or conditional blocks, as explained in Kito Mann's article in Java World. JSF 1.2 and JSP 2.1 will together bring better integration between JSF and JSTL tags, for example in allowing JSF tags to be used effectively within <c:forEach> and <c:if> tags.

Also missing from the standard set are more sophisticated components, such as the file upload and date picking components provided by Tapestry. Of course, you should have no trouble accessing these components for your JSF applications. There are already a rich array of JSF controls available from third parties, such as Oracle ADF Faces. The problem is potential incompatibility: if you use the ADF Faces components for example, you're most likely to end up replacing all of the standard components with ADF equivalents. If vendor independence is a goal, this is not desirable.

Tapestry

The first thing to note about Tapestry components is that pages are themselves components. If you're used to writing Tapestry page templates, then writing basic components only requires knowledge in a couple of new areas:

• firstly, component textual output can be created either using a component (HTML) template (which is essentially no different from a a page template) or by writing markup code in a Java class. Using component templates, it is particularly easy to write composite components. If your component writes its own markup you will need to create a component class extending BaseComponent, and implement renderComponent(). Tapestry provides you with an IMarkupWriter implementation which makes writing out markup content relatively easy

• secondly, unlike pages, components have parameters. Suppose for example you want to create a component which displays monetary values. This component takes three parameters: a float value, a Format object used to specify the format of the value, and the currency code. Here, the component can be built simply using two Insert component instances in a component template, with currencyCode, amount, and numberFormat as the three component parameters. This is what the component template HTML will look like:

       
  <span jwcid = "@Insert" 
          value = "ognl:currencyCode"/>&nbsp;
  
  <span jwcid = "@Insert" 
          value = "ognl:amount"
          format = "ognl:numberFormat"/>

  A page using the component simply includes attributes for each of the component parameters:

  <span jwcid = "@CurrencyAmount" currencyCode = "ognl:currencyCode" 
      amount = "ognl:amount" format = "ognl:decimalFormat"/>

  You don't need to write code to bind your parameters to page properties; Tapestry will do this for you in all but the most specialized situations.

  A useful feature is Tapestry's supports informal parameters, tag attributes not needed by the component itself but are still required for layout purposes. A good example is CSS class references. Informal parameters can be transparently rendered without the need for any component level declaration.

JSF

Compared with Tapestry, implementing a custom JSF component is a relatively demanding exercise. Unlike Tapestry, there are no similarities in the component development and page development models. Component templates are not supported, which means you need to write contained markup using Java code. JSF custom components will typically need to following:

• an implementation of the component class, which will extend UIComponent, normally by subclassing UIComponentBase or one of its subclasses. This class may contain fields used to hold component state

• an implementation of the JSP tag handler, which is used to set up binding between the JSP templates and component, and is usually a subclass of UIComponentTag

• optionally, the component can use an external renderer. One of the component's main tasks is to perform encoding by generating markup and decoding it by extracting inputted values from the request. Using an external render allows these roles to be delegated, opening up the possibility of different renderers being used for the same component

JSF

In JSF validation is a very generalized concept. Zero or more validators can be applied to any standard JSF input component, using tags such as the following:

<h:inputText required = "true" value = "#{holiday_backing.amount}" id="amountInput">
        <f:validateDoubleRange minimum = "0.1"/>
</h:inputText>

Similarly, JSF allows also you to separately specifiy either a standard or custom converter for any input component. In this case, the validation will be applied on the inputted value after conversion is successful. Here's an example:

<h:inputText required = "true" value = "#{holiday_backing.date}" id ="chooseDateInput">
        <f:convertDateTime pattern="yyyy-MM-dd"/>                 
</h:inputText>
  

JSF defines a component model for creating custom converters and validators. If validation or type conversion is unsuccessful, a component specific FacesMessage instance is is added to FacesContext. The message contains summary, detail and severity information.

Validation can also be delegated to a managed bean by adding a method binding in the validator attribute of an input tag. This mechanism is particularly useful for accomplishing form validation, where combinations of inputted values need to be evaluated to determine whether validation should succeed.

Outputting of form-level error messages is more problematic. The JSF core component set provide an HtmlMessages component, which simply outputs the summary message from all the FacesMessage instances added to the FacesContext during validation. In practice this is not very likely to be useful; you'll probably need to create an application specific mechanism for your project to handle this more acceptably.

Tapestry

Validation support is added through the IValidator interface. Unlike JSF, where validator functionality can be attached to any core input component, validation in the Tapestry 3.0 core components are limited specifically to text input fields components, namely ValidField and subclasses. For each of these, the template or page specification can be used to specify a IValidator class to be used for validation if a value is specified. If the field is required then this is set at the validator level. A fair number of IValidator implementations are provided out of the box, including validators for text, numerical fields, date fields, URLs, emails and patterns.

The scheme works well in most circumstances but there are some limitations. Validators cannot be attached to arbitrary form input components. Validation isn't supported for some core components, such as TextArea. Also, only one IValidator instance can be applied to a validating component, which makes the task of performing multiple validations somewhat problematic.

Where Tapestry in its current form comes through more strongly is in validation of the form as a whole. During validation, information about which fields have failed validation is stored in an IValidationDelegate instance. The IValidationDelegate can be subclassed to control how field labels are rendered for fields in error. The IValidationDelegate can also be used to output customized form specific error messages.

Tapestry's other major strength is support for client side validation. Unlike JSF, standard validators all have JavaScript-based client-side support.

Type conversion also works quite differently in Tapestry from JSF. For fields being validated, the validator itself is responsible for performing type conversion, a possible limitation if type conversion and validation need to be decoupled. For example, the DateValidator allows you to specify a date format for Strings to be converted to and from java.util.Date instances.

The Tapestry developers have recognized limitations in the existing architecture; Tapestry 4.0 will ship with a completely new mechanism for validation and type conversion. It will be possible to specify validators and type converters (translators) separately. It will be possible to attach multiple validators to a single component, and provide validators for a greater variety of the standard components.

JSF

Setting up internationalization in JSF is fairly straightforward:

• add entries in faces-config.xml indicating which locales are supported, and add corresponding localized properties files into your application's class path (under WEB-INF/classes)

• load the resource bundle you wish to use for a particular view into a into a variable, as shown in below: <f:loadBundle basename = "ApplicationMessages" var = "bundle"/>

• instead of using a hardcoded strings for textual output, use the <h:outputtext value = "#{bundle.messageName)"/>

• For parameterised messages, you can use the <h:outputformat/> tag, passing extra parameters in using nested <f:param> tags

• the locale can be detected automatically, or you can explicitly set the locale for a view by calling UIViewRoot.setLocale()

Tapestry

Localization support in Tapestry is equally straightforward

• for each component or page which needs to be localized, add corresponding locale specific properties file containing application messages

• use the key attribute to identify text which needs to be localized
  <span key="hello">Hello</span>

• for text that needs to be formatted with parameters, use the insert tag: <span jwcid="@Insert" value="ognl:messages.format('holidays_left', noDaysLeft)"/>

Tapestry also allows localized versions of templates files. This makes sense when templates consist of relatively large amount of text relative to formatting.

JSF

In general JSF managed beans are relatively free from framework specific dependencies. There are two exceptions: firstly, event handler methods will often need to use FacesContext to extract data required for processing. Secondly, it is possible, and sometimes necessary, to bind JSF UI controls to managed beans. For example, in the home page of our example application, this is necessary to identify the data for the selected row from the HtmlDataTable component. When these kinds of dependencies are present, mock objects will aid unit testing. Otherwise, standard unit testing techniques can be used with JSF.

Tapestry

Tapestry pages are harder to test than JSF managed beans for two reasons. First, your page classes must extend a Tapestry base class. Secondly, Tapestry encourages pages and their property accessors to be declared abstract, allowing them to be placed under the control of Tapestry's runtime. This has some advantages, but ease of unit testing is not one of them. The forthcoming version of Tapestry has support for instantiating these pages and components within a unit testing environment, but for the current version, you have to create your own mechanism for doing this.

Tapestry

Tapestry also offers a number of features that help productivity. The most important of these is the ability to design templates using any HTML editor, and to preview templates within a standard web browser without deploying to an application server. Other useful features include:

• "line precise" error reporting, where template or specification errors are identified and
  pinpointed to exact locations within the application
• an exception page which gives detailed error and environment information
• the Tapestry inspector, which gives a fairly detailed view of the state of the application

Tapestry does not rely heavily on tools. A couple of tools are available for the Eclipse IDE, which can be quite helpful. No WYSIWYG drag and drop visual design tools exist for Tapestry in the same way as for JSF.

JSF

JSF is by design well-suited to tool support; with a good visual tool, you should be able to assemble applications fairly quickly without having to write too much code. However, the absence of a browser-based preview mechanism makes you very reliant on the tool: your productively will depend heavily on how effectively you work with it, and how effectively it works for you.

Available JSF implementations appear to be less helpful in identifying application configuration errors. They don't for example provide line precise error reporting on the original JSPs. This may be partly because the JSF implementation controls a narrower range of the technology stack than does Tapestry, where the templating mechanism is internal to the framework.

Tapestry

Tapestry is reputed to have a fairly steep learning curve. Part of the reason is that it is very different from anything that most Java developers (with the exception of those familiar with Apple WebObjects) are used to. Some understanding of how the framework works is necessary to use it properly; simply treating it as a black box is likely to result in problems.

Barriers to entry are arguably raised with the imminent arrival of Tapestry 4. Tapestry 4 goes well beyond simple evolution of the framework; in many ways it is a complete overhaul of the way things work internally. The result is a more powerful, productive framework. However, additional learning is required. For example, you need to acquire at least a basic understanding of Hivemind. One problem is that documentation is still playing catch-up. A gap has opened between the newly introduced changes and features, and the documentation available for them.

JSF

While JSF is certainly more complex than Struts, it is probably conceptually simpler to understand than Tapestry. JSF has the benefit of many articles and already several books available to help new users to get accustomed with the framework. For Tapestry users there is currently only one real choice, Tapestry In Action written by Howard Lewis Ship, but this does not cover Tapestry 4.0 developments.

With all this material available, the new JSF developer will still need to take the trouble to learn a new set of JSP custom tags which are in many ways quite peculiar to JSF.

Third Party Components

Because Tapestry and JSF are component-oriented UI frameworks the availability and quality of third party components is important. JSF components are available from a wide variety of sources, from commercial vendors through to open source projects. A fairly long list is available on JSFCentral.com. The presence of third-party component sources for JSF is essential, firstly because the standard components are unlikely to meet the requirements of complex applications, and secondly because writing JSF components is not trivial. Third-party Tapestry components appear to be available almost exclusively through the open source community, and are provided in a more informal, grass roots kind of way. See the Tapestry Wiki for a list.

Specification vs Implementation

The success of non-standard open source frameworks such as Spring and Hibernate at the expense of EJB has reopened the debate on the value of standards in Enterprise Java. The value of standards increases for projects with large development teams, higher developer turnover, and for projects which use more junior developers. For such projects, JSF's position as a standard should appeal. Standardization also offers more protection from future API changes, as backward compatibility tends to be strongly enforced with JCP standards, and allows you to avoid being locked into a single implementation. Tapestry is of course not a standard, and I find it hard to imagine that it ever will be. It's more likely that Tapestry will influence the evolution of other standards, in particular JSF.

Availability of Jobs and Staff

Industry momentum is important for developers and project managers for complementary reasons; developers can find jobs and managers can find staff more easily if there is momentum behind the framework. The number of jobs requiring JSF skills is increasing, but still an order of magnitude fewer than those requiring Struts. Tapestry job postings are relatively few and far between.

JSF

JSF was designed from the outset to be extensible. It has a number of well-defined extension points, put to use by a growing number of third party framework add-ons. Not least of these is Struts Shale, currently being built using a new and completely different architecture and code base from Struts as most developers know it. The main extension points of JSF are:

• view handler: this part of the framework is responsible for handling the Render Response and Restore View phases of the JSF life cycle. An alternative ViewHandler implementation can be used for plugging in different display technologies, as in the case with Facelets and Shale's Clay plug-in
• state manager: responsible for saving and restoring a view's component tree. The StateManager is actually used by the view handler for both operations, but this use is fully decoupled. The state manager mechanism allows for pluggable component state management strategies
• navigation handler: responsible for selecting the next view to display based on the logical outcome of application actions. The behaviour of the default NavigationHandler is described in the 'Navigation' section of this article
• expression language: custom PropertyResolver and VariableResolver implementations can be supplied to extend the JSF EL, for example, by adding new implicit variables. For JSF 1.2, expression language extensibility will be through JSP EL mechanisms
• application and application factory: the Application and ApplicationFactory implementations can be customized to control how references to pluggable JSF objects are provided.

Applying customizations of each of these parts of JSF is simple; just register the appropriate entry in faces-config.xml. For example, configuring your JSF application to use the Facelets view handler requires the entry:

<application>
        <view-handler>
                com.sun.facelets.FaceletViewHandler
        </view-handler>    
</application>

Tapestry

The main framework extension point for Tapestry 3.0 is the application engine, a core object typically configured once for the application. Here's a flavour of what you can extend or modify by overriding the appropriate methods in your AbstractEngine subclass:

• property source: used to determine how configuration properties are loaded
• page source: used to provide access to tapestry pages
• specification source: used to provide access to page and component specification objects
• template source: used to provide access to parsed page and component templates
• data squeezer: used to handle conversions between Strings and Java objects
• component class enhancer: used to enhance page and component classes, in particular to provide support for page and component properties

This extensibility mechanism has been completely overhauled for Tapestry 4.0. The Tapestry 4.0 framework is now a collection of Hivemind services, many contributions to the tapestry.Infrastructure configuration point. Tapestry also exposes an tapestry.InfrastructureOverrides configuration point, specifically for the purposes of enhancing, decorating or replacing framework infrastructure services. The services that can be replaced include the ones described above, as well as many other new and existing ones. Various other parts of the framework, from persistence of properties to exception reporting, can also be extended or replaced by contributing to other Hivemind configuration points.