1: What actually happens in render response phase then?
Generating HTML output for the client, starting with UIViewRoot#encodeAll()
. You can see the result by rightclick, View Source in webbrowser (and thus NOT via rightclick, Inspect Element in webbrowser, as that will only show the HTML DOM tree which the webbrowser has built based on the raw HTML source code and all JavaScript events thereafter).
2: it is compared with the submitted value which would always be null on every post back
Nope, it's being hold as an instance variable. JSF doesn't call getSubmittedValue()
to compare it.
3: My point is, still when the conversion and validation is happening, what's the advantage of skipping the third phase?
This is answered in the bottom of the article, under Okay, when should I use the immediate attribute?. In a nutshell: prioritizing validation. If components with immediate="true"
fail on conversion/validation, then components without immediate="true"
won't be converted/validated.
4: What does the term retrieved value means?
The "raw" value which the enduser has submitted (the exact input value which the enduser entered in the input form). This is usually a String
. If you're familiar with servlets, then it's easy to understand that it's exactly the value as you obtain by request.getParameter()
.
5: Does JSF makes a list of some collection of these values and Apply Request Values and Process Validations phase iterate over them one by one?
Almost. The collection is already there in flavor of the JSF component tree. JSF thus basically iterates over a tree structure, starting with FacesContext#getUIViewRoot()
.
6: Then what does the last statement mean "Password forgotten" button in a login form with a required and immediate username field and a required but non-immediate password field.
This way you can reuse the login form for the "password forgotten" case. If you submit the "login" button, then obviously both the username and password fields must be validated. However if you submit the "password forgotten" button, then the password field shouldn't be validated.
That said, you may find the below JSF phases/lifecycle cheatsheet useful as well for a quick reference:
fc = FacesContext
vh = ViewHandler
in = UIInput
rq = HttpServletRequest
id = in.getClientId(fc);
1
RESTORE_VIEW
String viewId = rq.getServletPath(); fc.setViewRoot(vh.createView(fc, viewId));
2
APPLY_REQUEST_VALUES
in.setSubmittedValue(rq.getParameter(id));
3
PROCESS_VALIDATIONS
Object value = in.getSubmittedValue(); try { value = in.getConvertedValue(fc, value); for (Validator v : in.getValidators()) v.validate(fc, in, value); } in.setSubmittedValue(null); in.setValue(value); } catch (ConverterException | ValidatorException e) { fc.addMessage(id, e.getFacesMessage()); fc.validationFailed(); // Skips phases 4+5. in.setValid(false); }
4
UPDATE_MODEL_VALUES
bean.setProperty(in.getValue());
5
INVOKE_APPLICATION
bean.submit();
6
RENDER_RESPONSE
vh.renderView(fc, fc.getViewRoot());