El lenguaje de expresiones comenzó como una parte de la JavaServer Pages Standard Tag Library (JSTL) y fue llamado originalmente SPEL (Simplest Possible Expression Language), y después simplemente Expression Language (EL). Era un lenguaje de script que permitía el acceso a los componentes de Java(JavaBeans) a través de JSP. Desde JSP 2.0, se ha utilizado dentro de las etiquetas JSP para separar el código Java de JSP, y para permitir un acceso más fácil a los componentes de Java (que en código Java).Con los años, el lenguaje de expresiones ha evolucionado para incluir una funcionalidad más avanzada y fue incluido en la especificación JSP 2.0. El scripting se hizo más fácil para los diseñadores de contenido web que tienen poco o prácticamente ningún conocimiento del núcleo del lenguaje Java. Este lenguaje de script convirtió verdaderamente a JSP en un lenguaje de script. Antes de EL, JSP consistía en algunas etiquetas especiales como scriptlets, expresiones, etc. dentro de las cuales el código Java era escrito de forma explícita. Con EL el diseñador de contenido web sólo necesita saber cómo hacer las llamadas apropiadas a los métodos básicos de Java.EL era, tanto sintáctica como semánticamente, similar a las expresiones de JavaScriptno hay conversión de tipos explícita
las conversiones de tipos se hacen generalmente de forma implícita
las comillas dobles y simples son equivalentes
objeto.propiedad tiene el mismo significado que objeto['propiedad']
EL también liberó al programador de tener que conocer las particularidades de cómo se accede en realidad a los valores: objeto.propiedad puede significar (dependiendo de qué objeto se trata) o bien object.get("propiedad") o object.getProperty("propiedad") o object.getPropiedad(), etc.
Durante el desarrollo de JSP 2.0, la tecnología JavaServer Faces fue publicada, la cual también necesitaba un lenguaje de expresiones, pero el lenguaje de expresiones definido en la especificación JSP 2.0 no satisfacía todas las necesidades para el desarrollo con la tecnología JSF. La limitación más obvia es que sus expresiones son evaluadas de inmediato. Y también, los componentes de JSF necesitan una manera de invocar métodos de objetos del lado del servidor. Un lenguaje más poderoso fue creado con las siguientes nuevas características:
Expresiones diferidas, que no se evalúan de inmediato
Expresiones que pueden establecer (set), así como recuperar datos (get)
Expresiones de métodos, que pueden invocar métodos
El nuevo lenguaje de expresiones funcionó bien para los fines de JSF. Pero los desarrolladores tenían problemas en la integración de JSP EL con JSF EL debido a conflictos. Debido a estas incompatibilidades, la iniciativa "lenguaje de expresión unificado" comenzó para unificar estos lenguajes de expresiones. A partir de JSP 2.1, los lenguajes de expresión de JSP 2.0 y JSF 1.1 se han fusionado en un solo lenguaje de expresiones unificado (EL 2.1).
La versión 3.0 del lenguaje de expresiones (la palabra "unificado" ya no se consideró necesaria) se desarrolló en un JSR independiente de las especificaciones de JSP y JSF, en el JSR-341. Se agregaron algunas nuevas características, las más notables fueron los equivalentes en EL a los streams y expresiones lambda de Java 7.1El nuevo EL unificado es una unión de los lenguajes de expresiones de JSP y JSF. Además de las características ya disponibles en el EL de JSP, el EL unificado tiene las siguientes características:
Evaluación diferida
Soporte para expresiones que pueden establecer valores y expresiones que pueden invocar métodos
Una API enchufable para resolver expresiones
Lista de Operadores de EL
Lista de Orden de Precedencia
Objetos Implicitos
Son nombres de variables que hacen referencia a Objetos de uso común como el HttpServletRequest en un request, los Parámetros de Request etc.
<h:selectOneMenu value="#{formBean.form.formaPago}"
converter="#{formBean.converter}" label="forma Pago">
<f:selectItem value="#{null}"
itemLabel="-- Seleccione Forma de Pago --"></f:selectItem>
<f:selectItems var="item" value="#{formBean.formaPagos}"
itemLabel="#{item.label}" id="select_items"></f:selectItems>
</h:selectOneMenu>
<h:outputText value="El Cliente es Premium"
rendered="#{formBean.form.premium and !formBean.edit}"
style="border:1px solid red;background:red;color:white"></h:outputText>
<h:outputText value="#{formBean.form.id mod 2 == 0?'Par':'Impar'}"
rendered="#{!formBean.edit}"></h:outputText>
<h:outputText value="El Pago Fue contado"
rendered="#{!formBean.edit and formBean.form.formaPago.id==1}"></h:outputText>
<h:outputText value="El Pago No fué Contado"
rendered="#{!formBean.edit and formBean.form.formaPago.id ge 1}"></h:outputText>
En Publicaciones anteriorer hablamos del ciclo de vida del JSF, como crear un proyecto JSF y como hacer un ejemplo "Hola Mundo" con JSF.
Ahora "complicaremos un poco" más esto. enriqueciendo y haciendo interfaces gráficas Web más completas.
La Interfaz JSF típicamente se realiza programando o armando un Archivo llamado facelets, (puede ser un xhtml o un jsp), Es un documento XML estructurado donde por medio de etiquetas se va armando el formulario. JSF nos ofrece un conjunto de etiquetas de UI agrupadas en Bibliotecas. Donde cada etiqueta tiene alguna de característica que podemos dividir en estos grupos:
Inputs (Campos de Entrada)
Outputs (Salida)
Commands (Botones, UI de ejecución de Comandos)
Get Requests (Botones, Enlaces de Petición)
Selections (Campos de Chequeo, Listbox, menu, radio)
Html Pages (Head, Body, Form, CSS, Script)
Layouts (Paneles)
Datatable (Tabla de Datos)
Error and Messages
En el XML de acuerdo a la interfaz que se quiere realizar a partir del elemento raíz, se van agregando elementos. se puede representar como un Árbol
Core JSF - Geary
Cada uno de estas etiquetas están asociadas por una Clase Java que a su vez extiende de otra Clase Java, un componente UI de JSF extiende de la Clase UIComponent.html
El Elemento Nodo Raíz tambien es UIComponent tiene Clase UIViewRoot.html
A excepción del Nodo raiz(Árbol de UI), todos los otros elementos tiene un UIComponent Padre, y pueden tener muchos nodos hijos de clase UIComponent.
Como vemos en la imágen podemos tener un nodo Formulario, necesario para hacer un formulario y este va ser representado por uno de Clase UIForm y a este nodo le enriquecemos con componentes de clase UICommand e UIInput o UIOutput
Los UICommand e UIInput o UIOutput son Componentes de UI muy genéricos y podemos utilizar otros más específicos como (podemos ver que UIInput extiende de UIOutput )
De acuerdo a nuestras necesidades vamos a ir viendo todos los componentes que podemos ir utilizando, hay mucho material en la Web, y Tablas de Referencia.
En el ciclo de Vida de JSF, la primera fase es la de Restore View. En esta fase se obtiene el HttpServletRequest y se lee toda las información de Petición, URI, Método, Parámetros, Información de Cabecera y a partir de eso se recupera una instancia de un Objeto UIViewRoot. Si es la primera vez crea una instancia a partir del procesamiento del Facelets con su/s respectivos ManagedBean. Ese procesamiento genera un Arbol que tiene como raíz el UIViewRoot. Se procesa cada etiqueta y se genera un UIComponent con las etiquetas de UI y se completa la información necesaria a partir de las etiquetas de la Biblioteca Core u otras Etiquetas que no son de UI.
Cuando se utiliza un componente es importante ir conociendo las propiedades que uno puede utilizar, las más comunes que uno utiliza serían:
Para los componentes que implementan ValueHolder (UIOutput y todas las clases que extienden de ésta) es importante la propiedad "value" donde uno asocia por medio de un expresión JSF el valor que se va ligar value="#{bean.proX.subPropiedad}", que significa este componente tendrá como valor el valor de la propiedad "subPropiedad" del Bean que es propiedad "propX" del Managed Bean de nombre "Bean", Tambien tienen como propiedad converter, que es la Clase Converter que se encargará de mapear de Objeto a String, y String a Objeto a esa Propiedad.
Binding es una propiedad de los Tags de JSF que se utiliza para modificar propiedades del UIComponent asociando a una propiedad del ManagedBean.
Otra propiedad importante es "rendered" que significa que se mostrará si la expresión contenida retorna true (Verdadero), Todas los componentes (UIComponent) tienen propiedad rendered.
De acuerdo a la tabla de Referencia podemos ir por ejemplo a SelectOneRadio
Ejemplo (Form - Model)
package com.roshka.tutorial.jsf;
import java.util.Date;
public class Form {
private String name;
private Date birthdate;
private Integer id;
private FormaPago formaPago;
private boolean premium = false;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public Date getBirthdate() {
return birthdate;
}
public void setBirthdate(Date birthdate) {
this.birthdate = birthdate;
}
public Integer getId() {
return id;
}
public void setId(Integer id) {
this.id = id;
}
public FormaPago getFormaPago() {
return formaPago;
}
public void setFormaPago(FormaPago formaPago) {
this.formaPago = formaPago;
}
public boolean isPremium() {
return premium;
}
public void setPremium(boolean premium) {
this.premium = premium;
}
}
Ejemplo (FormPago - Model)
package com.roshka.tutorial.jsf;
import java.io.Serializable;
import java.util.ArrayList;
import java.util.List;
public class FormaPago implements Serializable {
private int id;
private String label;
public FormaPago() {
// TODO Auto-generated constructor stub
}
public FormaPago(int id, String label) {
super();
this.id = id;
this.label = label;
}
public int getId() {
return id;
}
public void setId(int id) {
this.id = id;
}
public String getLabel() {
return label;
}
public void setLabel(String label) {
this.label = label;
}
@Override
public boolean equals(Object obj) {
FormaPago formaPago = (FormaPago) obj;
if (formaPago == null)
return false;
return this.getId()==formaPago.getId();
}
static List formasPago = null;
static List getFormasPago() {
if (formasPago != null)
return formasPago;
formasPago = new ArrayList();
formasPago.add(new FormaPago(1, "Contado"));
formasPago.add(new FormaPago(2, "Crédito"));
return formasPago;
}
}
Ejemplo (Controller - FormManagedBean)
package com.roshka.tutorial.jsf;
import java.util.List;
import javax.faces.bean.ManagedBean;
import javax.faces.bean.ViewScoped;
@ManagedBean(name = "formBean")
@ViewScoped
public class FormManagedBean {
private String message = null;
private boolean edit = true;
private Form form;
private List formaPagos = null;
{
formaPagos = FormaPago.getFormasPago();
form = new Form();
}
public FormManagedBean() {
// TODO Auto-generated constructor stub
}
//accion modificar cliente
public String edit() {
message = String.format("Modificar {%s} {%s} {%s} {%s}", form.getId(),
form.getName(), form.getBirthdate(),
(form.getFormaPago() != null ? form.getFormaPago().getLabel()
: "- No se seleccionó Forma de Pago -"));
edit = true;
return null;
}
//accion guardar bean
public void save() {
message = String.format("Se guardó {%s} {%s} {%s} {%s}", form.getId(),
form.getName(), form.getBirthdate(),
(form.getFormaPago() != null ? form.getFormaPago().getLabel()
: "- No se seleccionó Forma de Pago -"));
edit = false;
}
public Form getForm() {
return form;
}
public void setForm(Form form) {
this.form = form;
}
public List getFormaPagos() {
return formaPagos;
}
public void setFormaPagos(List formaPagos) {
this.formaPagos = formaPagos;
}
public boolean isEdit() {
return edit;
}
public void setEdit(boolean edit) {
this.edit = edit;
}
public String getMessage() {
return message;
}
public void setMessage(String message) {
this.message = message;
}
}
JSF provee en su API un conjunto estándar de Bibliotecas de Etiquetas, para enriquecer o alimentar nuestra interfaz: Podemos alimentar nuestra interfaz con Paneles, Campos de Entrada, Campos de Salida, Grilla de Datos, etc.
Core
Html
Composite
JSF provee en su API, para en caso que estas librerías no alcance la necesidad, desarrollar bibliotecas adicionales con sus respectivas etiquetas.
Referencia de Bibliotecas Core, Composite y HTML de JSF
JSF2 standardizes Asynchronous Javascript and XML (Ajax) functionality across JSF component libraries and introduces the f:ajax tag to provide Ajax capabilities in a standard way.
The Subview tag creates a naming container (a container component with a unique identifier) that contains all JavaServer Faces core and custom tags on a nested page via "jsp:include" or any tag that dynamically includes another page from the same web application, such as JSTL's "c:import". The subview tag wraps JSF components contained in an included JSP or Facelets page that allows nested views.
Son los Componentes de Presentación, son utilizados para dar forma a la interfaz JSF
JSF HTML Tag Library
This tag library contains JavaServer Faces component tags for all UIComponent + HTML RenderKit Renderer combinations defined in the JavaServer Faces Specification.
The commandLink tag renders an HTML anchor tag that behaves like a form submit button and that can be associated with a backing bean or ActionListener class for event handling purposes.
The dataTable tag renders an HTML4 compliant table element that can be associated with a backing bean to obtain its data as well as for event handling purposes.
JSF 2.2 con MyFaces utilizando Maven (Lectura - Guía de Trabajo)
Maven
No existe motivos para no utilizar maven o alguna otra herramienta similar como Ivy,Gradle, etc para la construcción de un proyecto en Java, elegimos Maven por ser el más popular.
Maven Referencia(Wikipedia)
Maven es una herramienta de software para la gestión y construcción de proyectos Java creada por Jason van Zyl, de Sonatype, en 2002. Es similar en funcionalidad a Apache Ant (y en menor medida a PEAR de PHP y CPAN de Perl), pero tiene un modelo de configuración de construcción más simple, basado en un formato XML. Estuvo integrado inicialmente dentro del proyecto Jakarta pero ahora ya es un proyecto de nivel superior de la Apache Software Foundation.
Maven utiliza un Project Object Model (POM) para describir el proyecto de software a construir, sus dependencias de otros módulos y componentes externos, y el orden de construcción de los elementos. Viene con objetivos predefinidos para realizar ciertas tareas claramente definidas, como la compilación del código y su empaquetado.
Una característica clave de Maven es que está listo para usar en red. El motor incluido en su núcleo puede dinámicamente descargar plugins de un repositorio, el mismo repositorio que provee acceso a muchas versiones de diferentes proyectos Open Source en Java, de Apache y otras organizaciones y desarrolladores. Este repositorio y su sucesor reorganizado, el repositorio Maven 2, pugnan por ser el mecanismo de facto de distribución de aplicaciones en Java, pero su adopción ha sido muy lenta. Maven provee soporte no sólo para obtener archivos de su repositorio, sino también para subir artefactos al repositorio al final de la construcción de la aplicación, dejándola al acceso de todos los usuarios. Una caché local de artefactos actúa como la primera fuente para sincronizar la salida de los proyectos a un sistema local.
Convención sobre configuración
La filosofía general de Maven es la estandarización de las construcciones generadas por seguir el principio de Convención sobre Configuración, a fin de utilizar existentes modelos en la producción de software. Esta estrategia necesariamente restringe ampliamente la variabilidad, lo que se refleja en la exhortación de Maven a adherirse a su modelo de proyecto.3 Mientras que Maven es adecuado para nuevos proyectos, los proyectos complejos ya existentes pueden ser simplemente no adaptables para que utilicen Maven. La falta de restricciones de la convención de capas del proyecto fue hecha de alguna manera más configurable con el lanzamiento de Maven 2.
Reutilización
Maven está construido alrededor de la idea de reutilización, y más específicamente, a la reutilización de la lógica de construcción. Como los proyectos generalmente se construyen en patrones similares, una elección lógica podría ser reutilizar los procesos de construcción. La principal idea es no reutilizar el código o funcionalidad (como Apache Ant), sino simplemente cambiar la configuración o también código escrito. Esa es la principal diferencia entre Apache Ant y Apache Maven: el primero es una librería de utilidades y funciones buenas y útiles, mientras que la otra es un framework configurable y altamente extensible.4
Aunque Maven es configurable, históricamente el proyecto Maven ha enfatizado seriamente que los usuarios deben adherirse a su concepto de un modelo de proyecto estándar tanto como sea posible.
Ciclo de vida
Las partes del ciclo de vida principal del proyecto Maven son:
compile: Genera los ficheros .class compilando los fuentes .java
test: Ejecuta los test automáticos de JUnit existentes, abortando el proceso si alguno de ellos falla.
package: Genera el fichero .jar con los .class compilados
install: Copia el fichero .jar a un directorio de nuestro ordenador donde maven deja todos los .jar. De esta forma esos .jar pueden utilizarse en otros proyectos maven en el mismo ordenador.
deploy: Copia el fichero .jar a un servidor remoto, poniéndolo disponible para cualquier proyecto maven con acceso a ese servidor remoto.
Cuando se ejecuta cualquiera de los comandos maven, por ejemplo, si ejecutamos mvn install, maven irá verificando todas las fases del ciclo de vida desde la primera hasta la del comando, ejecutando sólo aquellas que no se hayan ejecutado previamente.
También existen algunas metas que están fuera del ciclo de vida que pueden ser llamadas, pero Maven asume que estas metas no son parte del ciclo de vida por defecto (no tienen que ser siempre realizadas). Estas metas son:
clean: Elimina todos los .class y .jar generados. Después de este comando se puede comenzar un compilado desde cero.
assembly:assembly: Genera un fichero .zip con todo lo necesario para instalar nuestro programa java. Se debe configurar previamente en un fichero xml qué se debe incluir en ese zip.
site: Genera un sitio web con la información de nuestro proyecto. Dicha información debe escribirse en el fichero pom.xml y ficheros .apt separados.
site-deploy: Sube el sitio web al servidor que hayamos configurado.
etc.
Pero estas metas pueden ser añadidas al ciclo de vida a través del Project Object Model (POM).
Fuente: Wikipedia
Crear Proyecto Maven con Eclipse
Utilizaremos Eclipse EE como IDE para hacer el ejemplo de nuestro proyecto JSF
File -> New -> Project
Importar dependencias de JSF
JSF no forma parte del Developer KIT o API básico de instalación, para poder ligar y relacionar las clases e interfaces de JSF necesitamos las librerias de JSF, podemos descargar y relacionar las librerías al proyecto o utilizar MAVEN y de manera descriptiva agregar la dependencia.
MyFaces - Implementación de JSF
JSF es una especificación, y existen diferentes Implementaciones que cumplen con la especificación. Utilizaremos ApacheMyFaces por ser una de las más populares
El API de Servlet tampoco forma parte del API Standard de JAVA y debemos agregar la dependencia para poder Compilar.
<dependency>
<groupId>org.apache.tomcat</groupId>
<artifactId>tomcat-coyote</artifactId>
<version>7.0.47</version>
<!-- provided no empaqueta la libreria utilizará una provista por el contenedor -->
<scope>provided</scope>
</dependency>
Configurar Faces Servlet
Para agregar JSF a un proyecto JSF se agrega un Servlet que actuará como Controlador, el FacesServlet. Este Servlet se encargará de procesar el Request y preparar el Response adecuado, Invocará los métodos necesarios para ir paso a paso en cada Etapa o Fase del JSF (Como vimos en el Ciclo de Vida de JSF) y terminar siempre en la Fase 6 o Fase de Render.
Invocará los métodos Setters y Getters de los Managed Bean necesarios y ejecutará los métodos actions que correspondan para el Request.
Una página o Interfáz JSF es expresada como XHTML o JSP y es procesada como Facelets.
El Servlet es configurado en el archivo web.xml dentro de la carpeta WEB-INF
Una vez definido el Servlet es necesario configurar en la aplicación reglas que se utilizarán para que el Contenedor de Servlets pueda identificar si corresponde o no que el Faces Servlet procese un Request.
Para eso se configuran reglas de Mapeos típicamente los FacesServlet procesan /faces/* o *.jsf lo que implica que todos los Requests que tengan URIs que cumplan con ese patrón serán procesados por el Faces Servlet.
Además configuramos un parámetro adicional para notificar al Servlet que vamos a estar en un ambiente de Desarrollo.
<!-- procesar todos los URI que empiecen con /faces ejemplo /faces/index.xhtml -->
<servlet-mapping>
<servlet-name>FacesServlet</servlet-name>
<url-pattern>/faces/*</url-pattern>
</servlet-mapping>
<!-- Parámetro adicional para informar que nuestro ambiente es de Desarrollo -->
<!-- Importante quitar el parámetro cuándo se pase a Producción -->
<context-param>
<param-name>javax.faces.PROJECT_STAGE</param-name>
<param-value>Development</param-value>
</context-param>
Configurar Faces Config
Una vez configurado el Faces Servlet, éste necesita de alguna configuración adicional para poder funcionar. Esta configuración puede ser:
Información de Locale (Localidad)
Mensajes
Managed Beans (Se pueden utilizar con anotaciones JAVA en lugar del XML)
Registro de Validadores JSF
Registro de Convertidores JSF
Reglas de Navegación
Resolvers *
Manged Properties (Inyección de Propiedades de Beans)
Kit Renderer *
Esta configuración puede estar ubicada en el archivo faces-config.xml dentro de la carpeta WEB-INF
<?xml version="1.0"?>
<faces-config xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd"
version="2.0">
<application>
<locale-config>
<!-- especificamos que nuestro formateo debe ser de Paraguay,
ej: separador de miles, Hora etc. -->
<default-locale>es_PY</default-locale>
</locale-config>
</application>
</faces-config>
Crear nuestro Primer JSF
Una Interfáz JSF se define o expresa en una Página Facelets, similar a un JSP utilizando librerías de Etiquetas de JSF (Core, HTML y adicionales)
Managed Bean son Componentes Java (Bean) que representan el Estado, manejan los Eventos y tienen los métodos de Acción a ser ejecutados de una Interfaz JSF (Un Managed Bean puede manejar varias interfaces y una Interfaz puede utilizar varios Managed Beans)
Para eso necesitamos Crear una Clase Java y convertirla en Bean:
Un Bean es una Clase Java que debe tener un Constructor vacio () y sus propiedades pueden ser accedidas por métodos GET y sus propiedades pueden ser modificadas por métodos SET
En el ejemplo crearemos un Bean Simple con una propiedad y un método Acción para ser invocado
package com.roshka.tutorial.jsf;
import javax.faces.bean.ManagedBean;
import javax.faces.view.ViewScoped;
@ManagedBean
@ViewScoped
public class MiBean {
// propiedad
private String mensaje;
// constructor vacio
public MiBean() {
// TODO Auto-generated constructor stub
}
// método GET para acceder
public String getMensaje() {
return mensaje;
}
// método SET para escribir
public void setMensaje(String mensaje) {
this.mensaje = mensaje;
}
// método a ser ejecutado en Fase 5
public String accion() {
mensaje = "Mostrar mensaje en Formulario JSF";
return null;
}
}
Hacer Despliegue en Contenedor de Servlets Tomcat
Integrar Tomcat en Eclipse
Buscamos la Pestaña de Servidores (Window -> Show View -> Server)
Despliegue de Proyecto en Eclipse
Click derecho en Tomcat para agregar proyectos al Servidor
Ya está adherido
Click derecho en Server Tomcar y le damos Start para arrancar
Si no hay ni un Problema vemos este mensaje
Probar nuestro Ejemplo
Abrimos el Browser de nuestra preferencia
y si tenemos un Tomcat configurado por Defecto abrira un proceso que escuchará en el Puerto 8080
Al dar Click en Ejecutar Debemos ver el siguiente mensaje
Conclusión:
1) Creamos un Proyecto JSF con las Librerías necesarias
2) Configuramos un Proyecto con los archivos web.xml y faces-config.xml
3) Definimos un pequeño ejemplo de Interfaz JSF con un xhtml y un Managed Bean con una propiedad y un Método Accion
4) Desplegamos y Probamos la aplicación en el TOMCAT
+15.03.18.png)
+19.28.16.png)
+16.41.03.png)
+16.25.39.png)
+16.25.50.png)
+19.04.34.png)
+19.04.20.png)
+19.05.17.png)
