miércoles, 24 de noviembre de 2010
jueves, 21 de octubre de 2010
Model View Controler
es imprescindible definir los papeles que van a desempeñar cada elemento de nuestra aplicación.
Una manera metódica de conseguir esto es usar el patrón de diseño Model View Controler.
Este patrón que se refleja en el siguiente esquema nos permite separar el código , la visualizacion y el acceso a datos.
Como se puede apreciar en la vista se consigue eliminar cualquier vestigio de código java nativo, apoyandose en las distintas herramientas que nos ofrece java.
El controlador se encarga de realizar las llamadas con los datos obtenidos de la vista y cargar el modelo que se va a utilizar (una lista de productos, un nombre,..)
Este modelo es cargado por la vista oportuna (se indica en el mismo controlador con redirecciones por ejemplo) que usando dichos datos solo debe concentrarse en mostrarlos en el formato deseado al usuario.
domingo, 17 de octubre de 2010
Filter
El uso de filtros es otra de las herramientas en el desarrollo de componentes web.
Ejemplos prácticos de su uso serían los que siguen.
Control de acceso: evitar el acceso a partes de nuestra aplicación/sitio si el usuario no está registrado.
Insertar fragmento de HTML (una cabecera o un pié ) a todas las páginas de nuestro sitio.
Evitar el “robo” de imágenes de una página a un usuario no registrado.
El planteamiento sería similar al de CSS (Cascading Style Sheet) o las hojas de estilo, en el que definimos aparte una apariencia que se aplica a todo nuestro sitio, agilizando los cambios y manteniendo el código ligero. Es preferible definir las directivas de acceso en un único lugar a tener que realizar las comprobaciones en todo el código.
El filter, como el servlet y el listener está ligado al archivo web.xml, por lo que este es un punto de partida a la hora de localizar un comportamiento no deseado por nuestro filtro (o servlet o listener).
public class FiltroAcceso implements Filter {
Ejemplo de control de acceso
NOTA:
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
Como se puede observar el tipo de request, del filtro es de tipo ServletRequest en vez de HttpServletRequest, por lo que si queremos poder acceder a los datos contenidos en los distintos ámbitos del request es necesario hacer modelado con el request para que se asemeje al que usamos en los servlets eso se hace como sigue:
HttpServletRequest httprequest=(HttpServletRequest)request;
HttpSession session=(HttpSession)httprequest.getSession();
publicvoiddoFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
HttpServletRequest httprequest=(HttpServletRequest)request;
HttpSession session=(HttpSession)httprequest.getSession();
Object atributo=session.getAttribute("usuario");
Usuario usuario=(Usuario) atributo;
if(usuario!=null)
chain.doFilter(request, response);
else{
request.getRequestDispatcher("./index.jsp?mensaje=Login para acceder a ese apartado").forward(request, response);}
}
El texto marcado en verde es el que gestiona la peticion, antes de dicho texto podemos hacer las operaciones que deseemos. En el ejemplo si hay un usuario logado atendemos su peticion, en caso contrario lo redirigimos a una pagina en concreto.
<filter>
<display-name>FiltroAcceso</display-name>
<filter-name>FiltroAcceso</filter-name>
<filter-class>filter.FiltroAcceso</filter-class>
</filter>
<filter-mapping>
<filter-name>FiltroAcceso</filter-name>
<servlet-name>ControladorBorradoProducto</servlet-name>
</filter-mapping>
<filter-mapping>
<filter-name>FiltroAcceso</filter-name>
<servlet-name>ControladorCarrito</servlet-name>
</filter-mapping>
Entre las etiquetas <filter> se define el filtro en las secciones. Las direccitas <filter-mapping> definen a que partes de nuestra aplicación se palica el filtro.
Listener
Un listener tiene distintos ambitos de aplicación. El asistente de eclipse nos ofrece los siguientes:
Distinguimos nuevamente tres tipos de ambitos, son los mismos que se vieron en servlets pero con diferente nombre:
ServletContext: Ambito de aplicación
HTTPSession: Ambito de sesión
ServletRequest: Ambito de petición
Así por ejemplo para conectar a una base de datos creariamos un listener de servletcontext, que se conectara al inicio de una peticion y se desconectará al terminar esta.
En el fichero web.xml un listener tendría el siguiente aspecto:
< listener >
<listener-class>listener.GestionConexionMysql</listener-class>
</ listener >
La clase java que implementa un listener tendria el siguiente aspecto:
publicclassListenerRequestimplementsServletRequestListener {
publicvoidrequestDestroyed(ServletRequestEvent arg0) {}
//Codigo a ejecutar antes de atender la peticion
publicvoidrequestInitialized(ServletRequestEvent arg0) {
//Codigo a ejecutar tras atender la peticion
}}
Es a través del implements como especificamos el ambito de la peticion.
Notese que se implementan requestDestroyed y requestInitialized
Servlet
El servlet es una de las partes mas importates en el desarrollo de componentes web con Java,
si bien la gestión de la presentación de datos hace que el uso de JSP sea más cómodo y recomendable.
El servlet al crearse se incluye en el archivo de definición web.xml, de igual forma se puede definir el servlet manualmente sin hacer uso del asistente de elcipse.
La definición de un servlet en el xml es la siguiente:
<servlet>
<description></description>
<display-name>Nombre mostrado</display-name>
<servlet-name>Nombre del servlet</servlet-name>
<servlet-class>Clase java</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Nombre mostrado en URL</servlet-name>
<url-pattern>/Ruta al recurso</url-pattern>
</servlet-mapping>
<servlet>
En cuanto a la clase java, su apariencia es la que sigue:
publicclassSERVLETextendsHttpServlet {
privatestaticfinallongserialVersionUID= 1L;
protectedvoiddoGet(HttpServletRequest request,HttpServletResponse response)throwsServletException, IOException {
}
protectedvoiddoPost(HttpServletRequest request,
HttpServletResponse response)throwsServletException, IOException {
}}
En los métodos doGet y doPost el servlet realiza su función.
Un error común es no redireccionar estos métodos.
Así si escribimos el código en el doGet(). El método doPost debe tener una llamada al anterior
doPost(HttpServletRequest request,HttpServletResponse response)
throwsServletException, IOException {
doGet(request,response);}
Está indicación es recomendable en ambos sentidos así, si usamos el doPost el doGet debe redirigir la petición al doGet.
La response del servlet da acceso a los siguientes objetos:
PrintWriter writer=response.getWriter();
writer.print("CODIGO HTML "+Valor de variable u objeto,...);
A través de request, se puede acceder a los siguientes campos:
request.getParameter("nombreVariable")
request.getSession.getAtribute("nombreObjeto");
request.getSession.getAtribute("nombreObjeto");
request.getSession().getServletContext ().getAtribute("nombreObjeto");
Las líneas anteriores definen los ambitos, estos pueden ser:
Request: petición, está "muere" al ser pintada.
Session: Sesión del usuario, para un usuario en concreto.
ServletContext: De aplicación, vive mientras esta se ejecute.
En las peticiones con getAttribute("VAR"), el objeto recuperado precisa del correspondiente casting que defina a que clase en particular pretece el objeto.
Al igual que recuperamos datos de distintos ambitos con getAtribute(""), también podemos almacenarlos haciendo uso de setParameter("NombreVariable",objeto) o setAtribute("NombreVariable",objeto)
El setParameter o getParameter solo tiene sentido en el contexto (scope) de la peticion (request).
Un método interesante del request es el siguiente:
request.getRequestDispatcher("./URL").forward(request,response);
Dado que la impresión/ generación de las vistas con SERVLET no es cómoda, normalmente el uso de servlet opera en la siguiente capa a las vistas (JSP) gestionando las redirecciones y las peticiones del usuario o sitio.
Desarrollo de componentes web con Java
Servlets
Filters
Listeners
JSP
Se detallarán las consideraciones de estos componentes en posteriores entradas, incidiendo en aspectos a tener en cuenta a la hora del desarrollo.
Los SERVLETs están fuertemente ligados al archivo web.xml de una aplicación web. Principalmente su función es una vez obtenidas las peticiones de la vista, dirigir dicha petición a la vista correspondiente, al servicio que procesa esos datos, ..
El JSP se centra en el campo de la representación de datos, para lo que hacemos uso de Expression Language y las etiquetas personalizadas. Son de uso habitual aquí el HTML y el CSS.
Los LISTENERs inicializan datos como puede ser una conexión a la base de datos o crear un elemento en el ambito de la aplicación.
Los FILTERs proporcionan una capa adicional en la seguridad y el control de las peticiones. Por ejemplo limitando el acceso a determinadas secciones si el usuario no está registrado.
Programación orientada a Evento POE
Mientras la programación orientada a objeto se centra en la estructura de los objetos, este enfonque de la programación se centra en sus relaciones.
El que un objeto “actue”, se cree u otra operación desencadena una serie de procesos, eventos, en los demas objetos.
Debemos considerar el evento como una situación que desencadena otra.
En la imagen se pueden apreciar los elementos que participan en este tipo de programación.
Launcher es el que genera un evento.
Dispatcher indica quien debe recibir el evento
Listener recibe u oye el evento y actúa cuando se produce.
En base a su relación podemos indicar lo siguiente:
Un launcher puede tener muchos eventos.
Un evento tiene un unico Launcher.
Un evento puede ser escuchado por muchos listeners.
Un Dispatcher solo tiene un launcher.
Un launcher puede tener muchos dispatchers.
Un listener puede atender a muchos dispatcher.
Un dispatcher puede repartir a muchos listeners.
En el campo del desarrollo de componentes web podemos encontrar en los listeners.
El siguiente es un ejemplo claro del diagrama anterior en el que se facilita la identificación de los actores.
Imaginemos la bolsa.
Tenemos una pizarra de valores (Es nuestro lanzador de eventos),
en el parque tenemos a los brokers (son los dispatchers), fuera tenemos a los clientes.
Así cuando un broker recibe un evento, por ejemplo la subida de una empresa en concreto, este transmite el evento a sus clientes como se muestra en el siguiente diagrama.
Este paradigma de programación, es de mucha utilidad en el diseño de interfaces gráficas de usuario (GUI) si bien en el desarrollo de componentes web su aplicación es limitada.
Enlaces: