JavaServer Faces

Dealing with Syntax Errors in User Input

In Chapter 6, we created a few components, arranged them as a component tree in a view, rendered them to the browser, and saved the view state either in the response itself or on the server. Presumably, there’s a user sitting there admiring our nice form with an input field and a button. Let’s see what happens when she submits the form.

First, JSF must figure out which view to use for processing the request. This information is encoded in the URI itself. As you may recall from Chapter 6, we’ve decided to use the default extension mapping for JSF requests, so the request paths always end with a .faces suffix. The view ID is the context-relative path with .faces replaced by .jsp. So with a context-relative path like /test.faces, the view ID is /test.jsp. JSF uses this ID to locate the state information on the server, or retrieve it from the request data if it was previously passed to the client with the response. It rebuilds the component tree, and then calls restoreState() on all components so they can get back their old internal state.

Next, each component is asked to look for its value in the request. JSF calls a method called decode() on each component to accomplish this task. As with rendering, components typically delegate this task to an associated renderer; if a renderer was used to render the component, it’s the one most likely to know how to find the component’s value in the request.

For HTML, component values are sent as HTTP request ...