JavaServer Faces 1.0 Early Access Draft (Page 2)

<< Page 1 (Introduction & Message Forum)

Data Model Duplication

Section JSF 2.1 talks about the process of transforming the HTTP request parameters into the UIComponent Tree and using the HTTP request parameter values to set the UIComponent Tree's local values. Section 2.5 continues by discussing (in no detail) the process by which the JSF implementation transfers the UIComponent Tree's local values into the Application's Model values. These steps in the JSF workflow are called the "reconstitute request phase" and the "update model values phase", respectively.

Most JSF implementations will be structured to accept requests in the following way:

HTML->HTTP->FacesServlet->reconstitute request phase->…->update model values phase

This leads to an enormous amount of duplication as well as overhead. The values for each UIComponent will be stored in the HttpServletRequest, expanded into the UIComponent Tree, and finally migrated to the Application's Model. Although this seems to be a small amount of work when considering smaller forms with two or three fields, it could become larger with 20-30 field forms. This continues to grow when considering an intensive web application with many users (i.e. 20+ requests per minute). In addition, the cost of the UIComponent and Application's Model classes themselves might further increase the amount of memory consumed by this triple duplication as they may contain other member variables that increase each instance's footprint.

Besides the memory consumption, most JSF implementations will probably use reflection to set the UIComponent Tree's local values. Although the Model references were not included in this draft, I'll assume that they will also use reflection. This is two or more reflections for every value (UIComponent), every request.

If, for example, the request goes all the way to the Invoke Application phase and then encounters an error, which will redirect the user back to the form so that they can fix some values, after they have fixed the values and resubmitted, this double transfer happens, in its entirety, again.

An alternative design would be single duplication of data. This would be from the HttpServletRequest to the Application's Model directly. This would remove the UIComponent's local values entirely. The UIComponent Tree could still be constructed from the HTTPServletRequest, but would not store the values from the request. Likewise, the UIComponent's themselves could be "backed" by the Application's Model classes as is the case in the MVC design of Java's Swing APIs.

The decoding process of transferring the data from the HTTPServletRequest to the UIComponent Tree would work the same but would store the decoded information in the Application's Model. Likewise, the encoding process of transferring the values back to the view (HTML) would retrieve the values from the Application's Model.

>> Page 3 (Request Event Handling)

<< Back to Programming