Confusion regarding a comment of JSF Postback with JSP as the view definition technology

1
votes

In chapter 5 named "Managed Beans and the JSF Expression Language" in the section named "Examining the Evolution of the EL:Deferrred vs. Immediate Expressions" of the book Java Server Faces 2.0 - The Complete Reference the authors write :

Immediate evaluation is perfect for JSP , but JSF needed something more . JSF introduced the request processing lifecycle (described in Chapter 3) , which governs what happens when the form is submitted (postback) . During a posback, the JSP page that rendered the mark up that is being posted back is not known and not available to the JSF runtime ;therefore, any expressions in that page are not available , since they were evaluated immediately when the page was rendered.

Why are the authors saying that the "During a posback, the JSP page that rendered the mark up that is being posted back is not known" ? Isn't this the exact responsibility of the restore view phase of the JSF lifecycle to restore the view described by the JSP view definition technology ?

1
jspjsfjsf-2jstlel

1 Answers

2
votes

No, the author means that there's no way to programmatically find the ${} EL expression references in order to evaluate them programmatically/individually. They are already been evaluated by the JSP engine once the JSF component tree is built based on JSP output. There are no references to ${} EL expressions in the JSF component tree. The #{} EL expressions are not recognized by the JSP engine and are therefore not directly been evaluated by the JSP engine. This way JSF can find them and turn them into ValueExpression references which allows programmatically evaluating by among others getValue() and setValue().

So, imagine that you've a

<h:inputText value="${bean.input}" />

then during the view build time the ${} would immediately be evaluated by the JSP engine and the value attribute would end up being the already evaluated value (as obtained by the getter). The JSF component's value would end up representing only the "literal" value which is the result the evaluation. There's no way to find out the original EL expression in its entirety in order to be able to set the model value on postback.