¡La versión 2.0 de Play ya está lista! Ayúdanos a traducir la documentación de la útlima versión y sigue nuestro progreso.

Manuales, tutoriales & referencias

Consulte

Contenidos

Elija la versión

Buscar

Busque con google

Libros

Play 1.0.2 — Cambios de la versión 1.0.2

Play 1.0.2 es una actualización de mantenimiento de la versión 1.0 de Play. Las principales novedades son el soporte para el repositorio de módulos y la protección integrada contra ataques CSRF. También se han solucionado numerosos bugs pequeños.

play 1.0.2 es una actualización de mantenimiento y es totalmente compatible con la versión 1.0. Si encuentra cualquier problema por favor pregúntenos en el grupo de Google.

Puede consultar la lista de los bugs corregidos en la página de avances de la versión 1.0.2. Los cambios más importantes están mencionados en esta página.

Repositorio de módulos

El objetivo del repositorio de módulos es centralizar todos los módulos que han sido desarrollados para el framework Play, y facilitar su instalación. Los nuevos comandos relacionados con la gestión de módulos son:

  • play list-modules, lista el contenido del repositorio de módulos
  • play install, instala una versión de un módulo de manera local
  • play new-module, crea el esqueleto para desarrollar un módulo
  • play build-module, empaqueta el módulo, preparándolo para su publicación en el repositorio.

Además notará que la mayor parte de los módulos han sido borrados. Solo un conjunto de módulos ‘esenciales’ está disponible localmente: testrunner, docviewer, crud and secure.

El resto de los módulos osn opcionales. De manera que si usted desea, por ejemplo, instalar soporte para GWT, solamente tendrá que tipear play install gwt, y obtendrá la versión más reciente del módulo.

¿Por qué hemos movido los módulos? Porque necesitamos concentrarnos en el propio framework, a fin de contar con un proyecto simple de administrar. Además, dado que muchas personas han empezado a contribuir con sus propios módulos, es mucho más fácil hacerlo de esta manera: cada módulo es un proyecto autónomo que tiene un desarrollador encargado de mantenerlo. De forma tal que, si desea reportar un error en un módulo específico, podrá dirigirse a la página principal del módulo y usar su propio sistema de tickets.

Un beneficio inmediato de este enfoque, es que el ciclo de vida de un módulo ya no depende del ciclo de vida del framework. Nuevas versiones de un módulo pueden ser liberadas mucho más seguido que las versiones del propio framework. Y finalmente, dado que el framework ya no contiene módulos opcionales, el tamaño de la distribución de Play se ha visto reducido a la mitad.

Lea más acerca del repositorio de módulos en esta página.

Protección integrada contra ataques de falsificación de petición en sitios cruzado (Cross-Site Request Forgery -CSRF)

Los ataques CSRF pueden crear muchos problemas en una aplicación web.

Esta forma de ataque funciona incluyendo código malicioso o un link a una página que accede a una aplicación web a la cual el usuario se espera que esté autenticado. Si la sesión de ese usuario no ha caducado, un atacante puede executar comandos no autorizados.

Para prevenir este ataque, lo primero que hay que hacer es utilizar los métodos GET y POST de manera adecuada. Eso significa que solo los métodos POST pueden ser utilizados para llevar a cabo una interacción que cambie el estado de la aplicación.

Para los request de tipo POST, la única manera de asegurar una acción crítica es implementando un token de auntenticidad. Play 1.0.2 tiene ahora una serie de funciones que facilitan la tarea:

  • un nuevo método checkAuthenticity() disponible en todos los controladores, que verifica que en los parámetros del pedido HTTP haya un token de autenticidad válido y envía una respuesta de “acceso prohibido” (forbidden) si no lo puede hallar
  • session.getAuthenticityToken() genera un token de autenticidad que solamente es válido para la sesión actual
  • #{authenticityToken /} crea un input oculto que puede incluir en cualquier formulario
De manera que, por ejemplo:
public static destroyMyAccount() {
    checkAuthenticity();
    …
}

Solamente funcionará cuando sea llamado desde un formulario que incluya un token de autenticidad apropiado:

#{form @ destroyMyAccount()}
    #{authenticityToken /}
    <input type="submit" value="destroy my account">
#{/form}

Por supuesto que puede agregar esto a un filtro ‘before’ si desea ejecutarlo para proteger todas las acciones de una jerarquía de controladores. Lea más en la guía de seguridad.

Soporte por defecto para el método HEAD

Play ahora responde automáticamente a pedidos de tipo HEAD si existe una ruta para el método GET. Esto ha sido implementado de esta manera porque así lo establece la RFC de HTML, que indica que todo recurso debe también responder al método HEAD.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

El método HEAD es idéntico al método GET, salvo que el servidor NO DEBE retornar un cuerpo en la respuesta HTTP. La metainformación contenida en los encabezados HTTP en respuesta a un pedido de tipo HEAD, necesariamente DEBEN ser idénticos a la información devuelta en respuesta a un pedido de tipo GET. Este método puede ser utilizado para obtener metainformación acerca de la entidad requerida por el pedido HTTP sin transferir todo el contenido de la misma. Este método es usualmente utilizado para probar la validez de los links, la accesibilidad y las modificaciones recientes.

De manea que cualquier request de tipo HEAD invocará su método de acción, pero el contenido de la respuesta no será enviado al cliente. Por supuesto que puede especializar este comportamiento agregando una ruta personalizada para responder a un pedido de tipo HEAD. Por ejemplo:

GET     /orders/{id}         Orders.show
HEAD    /orders/{id}         Orders.showHead

Nueva aplicación de ejemplo: ‘zencontact’

Esta nueva aplicación es un port de la aplicación de administracion de contactos basada en Wicket. También hay una versión en Scala disponible en el módulo scala, para aquellos que estén interesados.

Mejor soporte para despliegue en servidores

Hemos probado el despliegue de un archivo WAR generado con Play en diversos servidores de aplicaciones. Puede verificar la matriz de compatibilidad.

JBoss 4.2.x JBoss 5.x JBoss 6M2 Glasshfish v3 IBM Websphere 6.1 IBM Websphere 7 Geronimo 2.x Tomcat 6.x Jetty 7.x Resin 4.0.5

Nuevas funcionalidades para la acciones reversas en templates

La sintaxis @@, que le permite revertir una acción a un url absoluto, ahora puede utilizarse en los parámetros de un tag. Por ejemplo:

#{form @@save()}
…
#{/}

Es muy útil si usa el motor de plantillas para generar e-mails, en cuyo caso necesita expresar las URLs de manera absoluta.

Además, ahora contamos con soporte para el binding automático de objetos complejos. Por ejemplo, con esta acción:

public static void search(SearchParams params) {
    …
}

SearchParams, being:

public class SearchParams {
    public String keywords;
    public String mode;
}

Puede utilizar en una plantilla algo así:

@{search(params)}

Eso creará una URL con múltiples valores en el queryString, como el siguiente:

/search?params.keywords=xxxx&params.mode=AND

Un nuevo comando para generar los Javadocs

Ahora puede generar la documentación Javadoc para su proyecto de una manera muy simple, utilizando:

play javadoc 

Generará los javadocs de la documentación de la API de su proyecto y sus módulos.

Un plugin de Eclipse mejorado en esta versión

EL plugin de Eclipse trae ahora nueva funcionalidad:

  • Editor avanzado de rutas, con asistentes de contenido, detección de acciones faltantes e hiperlinks.
  • Editor avanzado de templates, con algunas capacidades de asistentes de contenido e hiperlinks.
  • Wizard para crear nuevos Controladores, Modelos y Templates
  • Ejecutador de pruebas integrado (utilizando un explorador web embebido)

Para instalar este plugin, copie el archivo JAR de $PLAY_HOME/support/eclipse a $ECLIPSE_HOME/dropins.

Próxima versión: Cambios en la versión 1.0.3 de Play