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