¡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.2 — Cambios de la versión 1.2

Puedes consultar las lista de bugs solucionados en Play 1.2 en la hoja de ruta. Esta página resume los cambios más importantes.

Migrando desde Play 1.1.x

Migrar desde Play 1.1.x es sumamente simple. No hay cambios en el layout de la aplicación, de forma tal que sus aplicaciones podrán ejecutarse en Play 1.2. Sin embargo, si usa algún módulo externo, posiblemente tenga que actualizarse a alguna versión compatible con Play 1.2. Verifique la documentación del módulo correspondiente.

Algunas APIs han sido eliminadas de Play 1.2, luego de haber sido deprecadas por un tiempo prudencial, pero la mayor parte de la API pública se ha mantenido sin cambios. Si se encuentra con problemas de compilación que no sabe cómo resolver, consúltenos en la lista de discusión de google.

A partir de esta versión, al llamar a un controlador desde un test funcional (FunctionalTest), la acción invocada se ejecutará en su propia transacción. Dado que el test en sí mismo también se ejecuta en su propia transacción, esto puede dar lugar a deadlocks. Así que es recomendable configurar su base de datos con transacciones READ_UNCOMMITED al ejecutar las pruebas. Si realiza las pruebas contra la base de datos en memoria H2, utilice la siguiente configuración:

%test.db.url=jdbc:h2:mem:play;MODE=MYSQL;LOCK_MODE=0@ 

Si no puede utilizar READ_UNCOMMITED para las transacciones de su base de datos, deberá ejecutar cada operación de JPA en su propia transacción, ya sea estableciendo las tansacciones de JPA manualmente (utilizando JPA.em().getTransaction()) o lanzando nuevos procesos usando Jobs.

Gestión de dependencias

El sistema de gestión de dependencias de Play le permite configurar las dependencias externas de su aplicación utilizando únicamente el archivo dependencies.yml.

Una aplicación de Play puede tener tres tipos de dependencias:

  • El framework de Play propiamente dicho, ya que toda aplicación de Play siempre depende del framework Play.
  • Cualquier librería de Java disponible como un archivo JAR instalado en el directorio lib/ de su aplicación.
  • Un módulo de Play (que de hecho es un fragmento de aplicación) instalado en el directorio modules/ de su aplicación.

Una vez que ha establecido estas dependencias en el archivo conf/dependencies.yml, Play se encargará de resolver, descargar e instalar todas las dependencias requeridas.

Por ejemplo, utilizando el siguiente archivo:

# Application dependencies
 
require:
    - play
    - com.google.guava -> guava r07
    - play -> pdf 0.2

Puede ejecutar `play dependencies` en la línea de comandos:

Internamente Play utiliza Apache Ivy, por lo que provee soporte para repositorios compatibles con Maven.

Mejor soporte para llamadas asincrónicas

En la versión 1.1 de Play era posible trabajar de manera asincrónica utilizando los Futures de Java y los métodos de los controladores waitFor(…) y suspend(…). Sin embargo, estas órdenes primitivas no eran muy fáciles de usar. Es por eso que en Play 1.2 hemos rediseñado el soporte para llamadas ascinrónicas.

Promises

En Play 1.2 introducimos el tipo Promise, que es una adaptación del tipo de dato Future de Java. De hecho, un Promise<T> es también un Future<T> de forma tal que lo puede usar como un Future estándar. Sin embargo, tiene también un agregado sumamente interesante: la posibilidad de registrar un callback usando onRedeem(…) que será invocado tan pronto como el valor retornado por el Promise esté disponible. Esto le permite al framework registrarse a sí mismo a los Promises y retomar el http request tan pronto como sea posible.

play.libs.F

El tipo Promise es parte de una nueva librería (play.libs.F) que introduce varias contrucciones propias de la programación funcional. También nos pareció que precisábamos contar con pattern mathching en Java. Lamentablemente Java no trae soporte nativo para pattern matching, y debido a la falta de construcciones funcionales, es bastante complicado agregarlo como una librería. De todas maneras, hemos logrado una solución que no está nada mal.

await(…)

Cuando su aplicación retorna valores que aún no están disponibles utilizando un Promise<T>, usted podrá pedirle a Play que espere hasta que el resultado “prometido” esté disponible antes de continuar procesando el pedido http. Para ser más claros, su código Java explícitamente podrá decir:

“Estoy esperando un resultado que estará disponible más tarde”

y el framework responderá:

“Entendido, detendré la ejecución de su código, reutilizaré el thread para atender otros pedidos http, y retomaré la ejecución de su código tan pronto como el valor prometido que está esperando esté disponible”.

Continuations

Dado que el framework precisa recuperar el thread que estaba utilizando a fin de utilizarlo para atender otros pedidos, tiene que suspender la ejecución de su código. En versiones previas de Play, el equivalente a await(…) era waitFor(…), el cual suspendía la acción y luego la volvía a llamar más tarde desde el principio.

Para lograr que sea más fácil trabajar con código asincrónico en Play 1.2, hemos desarrollado los Continuations, los cuales le permiten a su código ser suspendido y reanudado de manera trasnparente.

Response streaming

Dado que podrá ejecutar bucles sin bloquear el pedido http, seguramente querrá enviar información al browser tan pronto como alguna porción de la misma esté disponible. Para esto creamos el tipo de respuesta HTTP Content-Type:Chunked, el cual le permite enviar respuestas HTTP por tramos (chunks). El browser recibirá estos chunks tan pronto como sean publicados por su aplicación.

WebSockets

Mediante el uso de WebSockets podrá establecer un canal bidireccional de comunicación entre el browser y su aplicación. Con la versión 1.2, Play provee soporte para WebSockets.

Nueva aplicación de char de ejemplo

Todas estas nuevas funcionalidades son utilizadas en la nueva aplicación de chat de ejemplo, la cual muestra cómo desarrollar una aplicación de chat de tres maneras distintas:

  • Active refresh
  • Ajax with long polling
  • WebSockets

Mejoras en el archivo de rutas

El archivo routes ahora soporta un conjunto de nuevas prestaciones. Además, ahora también puede utilizar los caracters { y } en las expresiones regulares de una definición de ruta.

staticFile: mapping

Al igual que el anterior mapeo staticDir, ahora puede relacionar directamente un camino URL a un archivo estático.

# Serve index.html static file for home requests
GET     /home                   staticFile:/public/html/index.html

404 como una acción

Ahora puede usar directamente 404 como una acción para indicar un camino URL que debe ser ignorado por su aplicación, por ejemplo:

# Ignore favicon requests
GET     /favicon.ico            404

Método WS

El nuevo método WS le permite declarar una ruta que está mapeada a un WebSocket.

# A WebSocket
WS    /chat/messages            Chat.messages

Ahora puede utilizar la sintaxis @@{Chat.messages()} para generar la ruta URL reversa, como en:

ws://localhost:9000/chat/messages

Database evolutions

Cuando utiliza una base de datos relacional, necesita una manera de llevar registro y organizar los cambios en el esquema de la base de datos. Play evolutions, automáticamente gestiona estos cambios y actualiza su esquema.

También resolverá los conflictos que ocurren cuando múltiples desarrolladores trabajan en la misma aplicación.

Anotaciones para establecer el contexto de invocación (Invocation context annotations)

Play mapea cada invocación (un pedido HTTP, un mensaje de un WebSocket, o la ejecución de un trabajo asincrónico, por ejemplo) como una Invocation. Ahora puede agregar anotaciones a cada invocación que serán utilizadas por los plugins para indicar la manera en que deberá ser tratada esa invocaciónen particular.

Por ejemplo, el plugin JPA automáticamente abrirá una transacción de la base de datos por cada invocación, si una base de datos está configurada. Ahora, si no necesita una conexión a la base para una invocación en particular, puede anotar con @NoTransaction:

@NoTransaction
public static void index() {
    render();
}

Otra anotación le permite especificar una transacción de sólo lectura para una invocación en particular:

@Transactional(readOnly=true)
public static show(Long id) {
    Post post = Post.findById(id);
    render(post);
}

El concepto de contexto de invocación puede ser extendido a cualquier plugin.

H2 como la base de datos en memoria por defecto

Hemos adoptado la base de datos H2 como la base de datos en memoria de Play. Tiene mayor grado de compatibilidad con bases de datos de producción como MySql, de forma tal que experimentará menos problemas a la hora de desplegar su aplicación.

Además, H2 provee una consola Web, que puede invocar desde el url /@db desde cualquier aplicación de Play, usando db=mem en su arhivo de configuración.

Mejoras en el Test-runner

Hay varias novedades en lo que respecta al ejecutador de tests (test-runner)

Ejecute sus tests basados en JUnit desde cualquier JUnit test runner

Ahora puede ejecutar sus casos de prueba de Java directamente, desde cualquier JUnit test runner, como el que trae Eclipse.

Reportes Surefire

Ahora cualquier test de Java que ejecuta genera reportes SureFire, haciéndo más fácil la integación de sus pruebas con otros servidores de integración contínua.

Fixtures de YAML

Ahora puede cargar sus fixtures desde múltiples archivos YAML al mismo tiempo, e incluso usar el lenguaje de templates en las deficiones de sus archivos YAML para agregar contenido dinámico al mismo.

Múltiples IDs en modo de prueba

También puede crear más de una configuración para el modo prueba, especificando distintos IDs de framework que coincidan con test-*.

Hojas ayuda-memoria (Cheat-sheets) incluidas en la documentación

La documentación de Play ahora incluye varias hojas ayuda-memoria que le proveen una referencia rápida de las funciones más cómunes de Play, para que imprima y utilice como material de consulta.

Otras mejoras menores

Hay también otras mejoras menores, así como 130 bugs solucionados, incluyendo:

  • Nuevos métodos create() y validateAndCreate() para los modelos JPA.
  • Se agregaron las siguientes opciones al comando play: --pid_file=, --http.port=, --https.port=
  • Soporte para definición de los pares lenguaje-país (e.g. en-GB)
  • Binding automático de Map<String, String>, para valores múltiples, valores compuestos, etc.
  • Posibilidad de crear tus propios CRUD ObjectType.
  • El cliente play.lib.WS ahora soporta timeout.
  • Las cookies de Session ya no son enviadas si la sessión se encuentra vacía.