Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Design Time View Handlers"
(→Component Tree Construction) |
m |
||
| Line 9: | Line 9: | ||
# The construction and initialization of the view root. | # The construction and initialization of the view root. | ||
# The construction and initialization of the component tree. | # The construction and initialization of the component tree. | ||
| − | # Adaptation of the component tree to one or more view specification | + | # Adaptation of the component tree to one or more view specification meta-data (i.e. JSP, XHTML, XML). |
# Rendering of the component tree to the target (i.e. typically rendering to HTML). | # Rendering of the component tree to the target (i.e. typically rendering to HTML). | ||
# Store and retrieve view state between requests. | # Store and retrieve view state between requests. | ||
| Line 36: | Line 36: | ||
Note a key difference between the design time and run time here. First, the tree creation functions of ''createView'' and ''restoreView'' are folded into this method since the request vs. postback lifecycle stages that they demark at runtime, hold no meaning at design time (since the design time is simulating and not actually emulating the application). | Note a key difference between the design time and run time here. First, the tree creation functions of ''createView'' and ''restoreView'' are folded into this method since the request vs. postback lifecycle stages that they demark at runtime, hold no meaning at design time (since the design time is simulating and not actually emulating the application). | ||
| + | |||
| + | == View Meta-data Adaptation == | ||
Revision as of 18:00, 30 October 2007
This document is provisional and subject to change
Note: this document is provisional and subject to change.
Contents
Overview
The JSF specification allows users to configure custom view handlers for their web applications. The custom view handler can change the following aspects of an application:
- The construction and initialization of the view root.
- The construction and initialization of the component tree.
- Adaptation of the component tree to one or more view specification meta-data (i.e. JSP, XHTML, XML).
- Rendering of the component tree to the target (i.e. typically rendering to HTML).
- Store and retrieve view state between requests.
- Calculate locale and character encoding information for the target.
- Map viewId's to url's (action URL) that when invoked on a request, will restore the corresponding view.
- A number of other issues that vary between the 1.1 and 1.2 specifications.
The wide range of capabilities means that assumptions made by the JSF design time can be seriously invalidated by the introduction of a custom view handler. This document covers the significant design time implications of custom view handlers and outlines the requirements for a Design Time View Handler extension mechanism to allow adopters to handle them.
View Root Construction
The view is the basic addressable unit for creating and rendering responses to servlet page requests. A view consists of a tree of UIComponent objects that represent the logical structure of a JSF user interface. Each component tree is rooted at a UIViewRoot, which is a special UI component that is defined by the JSF API framework. It is the responsibility of the view handler to create, and optionally populate, the UIViewRoot upon the request for a particular view. (2.4.2.1).
The createView method on the ViewHandler interface is used at runtime to delegate construction of the UIViewRoot to the view handler. The design time view handler needs a parallel method:
abstract DTUIViewRoot createView(DTFacesContext facesContext, String viewId);
Component Tree Construction
The view handler may optionally populate the component tree for view in createView (2.4.2.1). It must also re-initialize the component tree for a view on a postback through the restoreView API interface (2.2.1). Although the component tree may be modified at any time prior to (or even during) rendering, the view handler is the primary actor in tree creation. Therefore, the design time must provide a mechanism through which the DTUIRoot can be populated with component information:
abstract populateView(DTUIViewRoot viewRoot, DTFacesContext context)
Note a key difference between the design time and run time here. First, the tree creation functions of createView and restoreView are folded into this method since the request vs. postback lifecycle stages that they demark at runtime, hold no meaning at design time (since the design time is simulating and not actually emulating the application).