sesiones - que es jsf
Depuración del ciclo de vida JSF: qué ocurre exactamente en cada fase (1)
1: ¿Qué sucede realmente en la fase de respuesta del renderizado?
Generación de salida HTML para el cliente, comenzando con UIViewRoot#encodeAll()
. Puede ver el resultado haciendo clic con el botón derecho, Ver código fuente en webbrowser (y NO mediante el clic derecho, Inspeccionar elemento en webbrowser, ya que solo mostrará el árbol DOM HTML que el navegador web ha creado en base al código fuente HTML sin formato y todos los eventos de JavaScript posteriores )
2: se compara con el valor enviado, que siempre sería nulo en cada publicación posterior
No, se mantiene como una variable de instancia. JSF no llama a getSubmittedValue()
para compararlo.
3: Mi punto es que, aún cuando la conversión y la validación están ocurriendo, ¿cuál es la ventaja de omitir la tercera fase?
Esto se responde en la parte inferior del artículo, en Aceptar, ¿cuándo debería usar el atributo inmediato? . En pocas palabras: priorizar la validación. Si los componentes con immediate="true"
fallan en la conversión / validación, los componentes sin immediate="true"
no serán convertidos / validados.
4: ¿Qué significa el término valor recuperado?
El valor "en bruto" que el usuario final ha enviado (el valor de entrada exacto que el usuario final ingresó en el formulario de entrada). Esto usualmente es una String
. Si está familiarizado con los servlets, entonces es fácil entender que es exactamente el valor que obtiene por request.getParameter()
.
5: ¿JSF hace una lista de alguna colección de estos valores y la fase Aplicar valores de solicitud y validación de proceso itera sobre ellos uno por uno?
Casi. La colección ya está allí en el sabor del árbol de componentes JSF. JSF básicamente itera sobre una estructura en árbol, comenzando con FacesContext#getUIViewRoot()
.
6: Entonces, ¿qué significa la última declaración con el botón "Contraseña olvidada" en un formulario de inicio de sesión con un campo de nombre de usuario requerido e inmediato y un campo de contraseña requerido pero no inmediato.
De esta forma, puede reutilizar el formulario de inicio de sesión para el caso "contraseña olvidada". Si envía el botón "iniciar sesión", entonces obviamente los campos de nombre de usuario y contraseña deben validarse. Sin embargo, si envía el botón "contraseña olvidada", el campo de contraseña no debe validarse.
Dicho esto, puede encontrar útil la siguiente hoja de claves de fases JSF / ciclo de vida para una referencia rápida:
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());
Ver también:
He decidido profundizar completamente en JSF 2.0 ya que mi proyecto exige un profundo conocimiento del mismo. Estoy leyendo JSF Lifecyle Debug , un artículo bien escrito y sorprendente sobre el ciclo de vida de JSF. Mientras leo este artículo, tengo las siguientes confusiones.
Si se trata de una solicitud inicial, en la
Restore View Phase
deRestore View Phase
se crea una vista vacía y se produce unaRender Response Phase
directa. No hay estado para guardar en este punto. ¿Qué sucede realmente en larender response phase
? Estoy un poco confundido mientras ejecuto el ejemplo.El artículo establece que, el valor de entrada recuperado se establece en
inputComponent.setSubmittedValue()
en la faseApply Request Values
. Si pasa la validación y la conversión, el valor se establece eninputComponent.setValue(value)
yinputComponent.setSubmittedValue(null)
ejecuta. En el mismo punto, el artículo indica que, ahora si en la próxima solicitud posterior a la publicación, se cambia el valor, se compara con el valor enviado, que siempre será nulo en cada publicación posterior, sealue change listener
. Significa que, si no cambiamos el valor, ya que submittedValue sería nulo, ¿siempre se invocará valueChangeListener? Estoy confundido en esta declaración. ¿Puede alguien dar más detalles sobre esto?El artículo indica el uso del atributo
immediate
. Si el atributoimmediate
se establece en un componente de entrada, idealmente se omite laProcess Validation Phase
, pero toda la conversión y validación ocurre enApply Request Values
. Mi punto es que, aún cuando la conversión y la validación están ocurriendo, ¿cuál es la ventaja de saltearse la tercera fase?¿Qué significa el término valor recuperado?
Me gustaría saber si, digamos, hay cinco campos en la vista. ¿JSF hace una lista de alguna colección de estos valores y la fase
Apply Request Values
yProcess Validations
itera sobre ellos uno por uno?En el último punto de este artículo donde dice, cuándo usar el atributo
immediate
. Según mi comprensión, si el atributo inmediato se establece en el componente de entrada y el componente de comando, omitirá las fases desde Aplicar valores de solicitud a Solicitud de invocación para cualquier atributo que no tengaimmediate
. Entonces, ¿qué significa la última declaración con el botón "Contraseña olvidada" en un formulario de inicio de sesión con un campo de nombre de usuario requerido e inmediato y un campo de contraseña requerido pero no inmediato.
Sé que estas son confusiones muy básicas, pero la claridad en estos temas definitivamente ayudará a agudizar el conocimiento de JSF.