El camino a la web en Java con Play! - Parte 1
Introducción:
Hace tiempo (cerca de unos 3 años) me encontraba estudiando el grado TSU. Siempre interesado en la carrera (TI, programación en específico) me llamó mucho la atención (desde hace cómo 8 años) la programación y creación de sitios y aplicaciones en la web.
¿Porqué me llamaba la atención?
La razón es porqué siempre me ha gustado la comodidad (no me lo tomen a mal), y creía que para las personas era más cómodo memorizar "mipaginita.com"; y desde cualquier punto (y dispositivo) con acceso al servidor (por medio de la red) poder hacer uso de tus recursos de la oficina sin la necesidad de estar presencialmente.
La elección del framework y el comienzo de una migraña:
Dado a los hace casi 2 años que me encontraba por terminar el TSU, me puse a aprender a programar en Web por una clase, la famosa clase de "Desarrollo de aplicaciones web", que no es más que "Yet another class in which you'll learn nothing about ${insert theme, please}" (en castellano: "Sólo otra clase en la que no aprenderás sobre: ${por favor, inserte tema aquí}"), lo digo así porqué el profe era de esos huevones flojos que barqueaban, no enseñaba nada pero dejaba una lección muy buena; cuando uno le preguntaba algo [al profe] te respondía:
Te presento la fuente del conocimiento y el mejor instructor en la red: Google
Y pues a buscar con qué desarrollar y la breve historia:
- PHP. Lo que no me gustó de PHP fue la mezcla de código fuente de programación, con la interfaz, con la lógica, con los modelos, etc. se me hizo un "chile con queso". Razón por la que lo dejé de lado, existen frameworks cómo Akelos y Symfony, que ayudan a esto, pero aún así no me parecieron del todo buenos.
- ASP .NET (C#). Pues cómo en la escuela llevábamos C# desde el segundo tetra de la carrera, me quise ir por este camino, pero realmente no me gustó, de entrada es de paga y sólo corre en Windows. Da muchas facilidades, pero las cosas que yo utilizo me gusta que sean multiplataforma (porqué yo uso Linux).
- Java EE. Java me gustaba cómo lenguaje, por lo de ser multiplataforma, parecido a C# (en cuanto a sintaxis) además de muy apoyado. Lástima que nadie me había dicho el problemón que se cargaba con cuestiones de configuraciones.
Y pues ese era todo mi horizonte, por lo que seguí buscando en Java, después de mucho buscar me topé con Play, para ver que es Play! puedes revisar mi mi otro post que habla sobre él. Ahora vamos a una parte de las tres básicas que componen el uso de Play! y estos son los Modelos.
Modelos
Los modelos, así una definición rápida y concisa no son otra cosa más que los objetos encargados de interactuar con la base de datos, estos incluyen ya métodos cómo eliminar, guardar, leer, y modificar.
Bueno cómo decimos por acá: "a lo que te truje chencha":
Después de instalar Play! (no es más que bajarse el comprimido desde aquí, descomprimir en una carpeta y agregar la carpeta descomprimida a la variable PATH del sistema) tecleamos lo siguiente en una terminal o línea de comandos:
Damos enter y pedirá el nombre del proyecto (para mostrarlo en el título de la aplicación), tecleamos el nombre del proyecto, damos enter y listo, ya tenemos todo lo necesario para comenzar la aplicación.
Ahora, tomemos un pequeño vistazo a lo que ha creado:
De momento nos concentraremos en estos directorios que son los primordiales. Si se fijan tenemos bajo el directorio "app" tres carpetas: controllers, models y views; en donde van correspondientemente los controladores, los modelos y las vistas. Ahora bajo el directorio "app/models" crearemos una clase:
Con esto no estamos haciendo más que decir que la clase Persona, será en una base de datos una tabla. Pero aquí surge la duda, siendo un principiante podrías decir: ¿Qué base de datos, cómo lo averigua?. Ahorita lo veremos. Siendo alguien que ya ha utilizado JPA seguro dirías: Ah si, faltó agregar el directorio META-INF y dentro de ese directorio agregar el archivo persistence.xml. Para este último (quien ya haya utilizado JPA) la respuesta es no.
Recuerdan en el listado de arhivos y directorios de arriba un directorio llamado "conf", bueno dentro de "conf" podemos encontrar un archivo "application.conf", ahí buscamos las siguientes líneas:
Cómo ven es cómo un típico archivo de configuración no-xml. Basta con cambiar los valores en (dependiendo el método que uses el de arriba o el de abajo, con el primero te quedaría:
Con el segundo método quedaría:
Y con esto nos bastaría para dar nuestros primeros pasos en la web. Con esto podemos empezar a planear nuestros modelos de nuestra aplicación. La siguiente entrega será sobre los controladores.
Espero sus comentarios, sugerencias, etc.
De aquí puedes seguir a la parte 2.
- wishmaster77's blog
- Inicie sesión o regístrese para enviar comentarios
Primeros pasos en Web Java
Yo he tenido algunos problemas con Java (JSP), no sé usar correctamente ningún Framework (de los "miles" que hay). Se me complica usar Spring, Hibernate, etc.
Lo fácil sería seguir con PHP, ya que según yo es más fácil de usar.
Voy a probar este (no lo conocía), haber que pasa y si me convence.
Buen post.
Re: Primeros pasos en Web Java
Estoy preparando para entre hoy y mañana la segunda entrega. Que es donde vienen las cosas un poco más interesantes. Obviamente se habla a nivel muy muy básico, después, ya empezaremos a hablar de los módulos y plug-ins del framework. Y terminaremos con un post haciendo algún ejemplo clásico (blog, algún crud sencillo o algo por el estilo). Espero y te guste; ya que Play! maneja implícitamente cosas de Spring y en este caso (de los modelos, discutido en el post) ya estamos usando hibernate, pero, ¡NO HEMOS CONFIGURADO NADA!
;)
Libs.
¿Play! ya incluye los drivers para las BD comunes o dónde integras el jar que corresponde? No veo directorio /lib.
Salute.
Re: Libs.
Así es @benek, dentro del $PLAY_HOME/framework/lib puedes encontrar varias librerías te paso el find:
/framework/lib/
/framework/lib//.DS_Store
/framework/lib//activation-1.1.1.jar
/framework/lib//antlr-2.7.6.jar
/framework/lib//async-http-client-1.2.0.jar
/framework/lib//bcprov-jdk15-145.jar
/framework/lib//c3p0-0.9.1.2.jar
/framework/lib//cglib-2.2.jar
/framework/lib//commons-beanutils-1.8.3.jar
/framework/lib//commons-codec-1.4.jar
/framework/lib//commons-collections-3.1.jar
/framework/lib//commons-email-1.2.jar
/framework/lib//commons-fileupload-1.2.jar
/framework/lib//commons-io-1.4.jar
/framework/lib//commons-lang-2.5.jar
/framework/lib//commons-logging-1.1.1.jar
/framework/lib//dom4j-1.6.1.jar
/framework/lib//ehcache-core-2.0.0.jar
/framework/lib//ezmorph-1.0.3.jar
/framework/lib//groovy-all-1.7.1.jar
/framework/lib//gson-1.4.jar
/framework/lib//hibernate-annotations-3.5.6-Final.jar
/framework/lib//hibernate-commons-annotations-3.2.0.Final.jar
/framework/lib//hibernate-core-3.5.6-Final-patched.jar
/framework/lib//hibernate-entitymanager-3.5.6-Final.jar
/framework/lib//hibernate-jpa-2.0-api-1.0.0.Final.jar
/framework/lib//hsqldb-1.8.1.2.jar
/framework/lib//jamon-2.7.jar
/framework/lib//javamail-1.4.3.jar
/framework/lib//javassist-3.9.0.GA.jar
/framework/lib//jaxen-1.1.jar
/framework/lib//jj-imaging.jar
/framework/lib//jj-simplecaptcha.jar
/framework/lib//jj-textile.jar
/framework/lib//jj-wikitext.jar
/framework/lib//jodatime-1.6.jar
/framework/lib//jregex-1.2_01.jar
/framework/lib//jsr107cache-1.0.jar
/framework/lib//jta-1.1.jar
/framework/lib//junit-4.8.1.jar
/framework/lib//log4j-1.2.15.jar
/framework/lib//memcached-2.4.2.jar
/framework/lib//mysql-connector-java-5.1.13-bin.jar
/framework/lib//netty-3.2.2.Final.jar
/framework/lib//org.eclipse.jdt.core_3.6.0.jar
/framework/lib//oval-1.50.jar
/framework/lib//provided-servlet-2.5.jar
/framework/lib//signpost-core-1.2.jar
/framework/lib//slf4j-api-1.6.1.jar
/framework/lib//slf4j-log4j12-1.6.1.jar
/framework/lib//snakeyaml-1.6.jar
Además de varios módulos (plug-ins) para el framework. Y cómo Play! trata de trabajar con DRY lo más que se pueda, no incluye en /ilb las librerías "bundled" en el framework *. El directorio /lib es para librerías que no están "bundled" en el framework.
Notas:
* En tiempo de desarrollo Play! no las incluye, sino al final cuando cambias tu modo de desarrollo a producción; en donde en /lib se incluyen las librerías utilizadas.
Una alternativa a Grails
mmm creo que es muy parecido a grails,
Grails
Le voy más a Grails, una por estar en Groovy y otra porque el GORM es finalmente un frontend para Hibernate.
Pero... si estás restringido a usar Java, y no te permiten usar Groovy en un proyecto, Play es una buena alternativa.
Re: Una alternativa a Grails
No, realmente no. Grails es una alternativa a RoR con base en Groovy y con algunos vicios de Java. Grails es muy (a mi parecer) Spring-like; play es muy diferente, si bien te apoyas un poco en la consola cómo para crear un nuevo proyecto y para empaquetarlo no la utilizas para crear modelos o controladores (a mi parecer es más simplista que Grails); además que no tienes necesidad de aprender otro lenguaje (por más simple que este sea).
Re: Grails
Pues con Play!, no notas el intermedio cómo con GORM. De hecho si te fijas sólo se ha utilizado JPA + Hibernate, sin ninguna configuración, no necesité de otra herramienta. Pero pues el gusto se parte en géneros.
Y es la razón por la que uso Play!, porqué cuando no puedo usar RoR (cuestiones de lenguaje o plataforma) siempre está un framework RoR-Like.
Performance
He aquí una comparación de performance entre node.js y Play!, que considero interesante (pero sería mucho más interesante si incluyera un tercero como Grails o algún otro framework en JVM).
Re: Performance
El autor de Play! (Guillaume Bort) comentó algo en esa entrada de hecho. El comentario dice:
Y es algo bien cierto (y de cierta manera lógico), cuando carga play en producción necesita compilar todo dinámicamente (y lo hace "al vuelo"), después de eso no hay más de qué preocuparse. Ahora, hay que recordar que además tenemos la opción de utilizar containers cómo Tomcat o Glassfish (en donde se compila todo y luego se hace un war).
Respecto a Grails, creo que la ventaja en desempeño sería en todo caso de Play!, debido a que éste usa Groovy en una pequeña parte del framework (el sistema de templates) fuera de ahí el resto de los componentes corren en Java (las entidades y controladores al menos). Algo que desconozco es si Grails, permite usar Java para los modelos y entidades; de ser así es probable que el desempeño de ambos sea muy similar.
Otra cosa a tomar en cuenta es que con Play! podemos utilizar Scala que (a mi suponer) nos ayudaría a ganar algo de desempeño y manejo de concurrencia (una de las razones para las que se concibió Scala).
¿O qué opinas?
groovy/java
En Grails puedes usar Java para los modelos (que a fin de cuenta son un vil mapa con objetos, pero pues le metes objetos en Java). En cuanto a entidades, Grails usa Hibernate, y permite que importes entidades que ya tengas hechas en Java.
Sin embargo algo que considero muy importante, es el tiempo de desarrollo. A menos que la diferencia de performance entre Play, node.js y Grails fuera abismal, creo que pesa más el tiempo de desarrollo que el tiempo de ejecución. Si una app node.js corre 10% más rápido que la misma app hecha en Play!, pero tiene más código o tomó más tiempo desarrollarla (digamos, el doble de tiempo), entonces en realidad es más productivo Play. Consideremos que para un desarrollo de tamaño ya considerable, si el tiempo de desarrollo en un framework será de 500 horas mientras que en el otro será de mil horas, creo que hay que irse por el de 500 horas y seguramente una inversión adicional en hardware costará menos que las 500 horas adicionales de desarrollo (que además se traducen en horas adicionales posteriormente en mantenimiento, correcciones, modificaciones, etc).
Re: groovy/java
Mucha razón que te cargas...
Ahora en cuanto a productividad, pues de verdad que antes de checar Play! usé Grails (por ser un lenguaje que corre sobre java y tal), de verdad que no me agradó mucho en sí digamos por Groovy (no me agrada la sintáctica groovilera); de hecho Grails se me hizo ver Rails en otro lenguaje (Groovy on Rails, por llamarle de una manera). Sin embargo por tener algo que me gusta y algo que no pues decidí probarle y era casi todo lo que buscaba, era productivo y flexible (dada la "naturaleza" de Groovy); pero tenía Groovy no me terminó de convencer.
Por otro lado, empecé con Play! y la neta pues se me hizo chido, porqué no tuve que adaptarme a otro lenguaje más (por más sencillo que este fuera) y además tenías algunas ventajas propias de Grails y otras de Rails, además de buenas ideas de los creadores del framework (Zenexity). Algo que vi cómo ventaja de Play sobre Grails es que Play no es tan Spring-like (de verdad que en lo que he usado Java -y Spring por consecuencia- no termino de entender que es Spring), digamos que Play! es el framework más rebelde que he visto en Java.
En fin, regresando...Pues me puse a hacer un proyecto con Play! y otro con Grails; la diferencia la vi en tiempo, aunque te ahorras algo de lineas con Grails (sobretodo por eso de las closures).
Personalmente llegué a la conclusión que Play! era lo que buscaba (en Java, claro está...ya que después de conocer Scala y Lift, puedo decir que eso si era lo que buscaba para desarrollo web =D). Algo productivo, en este mundillo web ;)...No niego que Grails sea excelente framework y para muestra está que casi todo el mundo que vive con JEE ahora se pasa hablando de Grails...otros pocos de Scala. Creo que Grails y Groovy en general son el nuevo boom.