Gracias a un post de Mamen Pradel, descubro el curioso Wordle, del que ya había visto resultados pero no sabía de dónde venían (lo sé, debería haber preguntado :)).

Aquí el que he hecho hace un rato:

Como curiosidad, está hecho con un applet java, y ha sido desarrollado por Jonathan Feinberg, empleado de IBM Research

Ayer estuve leyendo los posts de Matt Raible sobre la OSCON 2008, recomiendo darles una ojeada a todos.

También ha publicado su propia charla en el evento, sobre frameworks de futuro:

Bajo mi punto de vista, osea en España donde en una inmensa mayoría de empresas aún no se plantea dejar el incombustible Struts 1, pienso que sobre Rails y Flex se puede decir que ya están aquí, ya que tienen cierta cuota de mercado; mientras que de GWT y Grails conozco muy pocos casos donde se esté(estemos) utilizando.

Me gustaría conocer de los que os pasáis por aquí, además de qué framework/s web estáis usando, cuáles son los que llaman vuestra atención. Personalmente me interesa seguir aprendiendo más sobre Grails y Rails, pero además también me llaman la atención GAE, CodeIgniter y Wicket para los que espero sacar tiempo, algún día :P.

Ayer lunes se hicimos el anuncio oficial del inicio del desarrollo de flatee (la mejor manera de compartir piso ;)), que vamos a desarrollar entre Jesús Navarrete y un servidor.

El proyecto surge dentro del internship que estamos haciendo en Linking Paths y a raíz de una necesidad personal, los actuales portales de clasificados no cubren mis necesidades como deberían y por lo que he hablado con más gente, no soy el único.

Estoy convencido que será una experiencia muy enriquecedora, no va a ser desarrollar algo y ya está, tendremos que cubrir todos los aspectos para que resulte un proyecto exitoso, tanto técnicos como no técnicos.

Por lo que si te interesa el proyecto en sí, crees que pueden existir mejores formas que ayuden elegir con quién y dónde vas a convivir o simplemente tienes curiosidad por saber como evoluciona el proyecto, no dejes de seguir el blog de flatee donde compartiremos nuestras experiencias, ideas... ¡esperamos tus opiniones! :)

Desde que empezó el Google Summer of Code no he explicado exáctamente qué es y el por qué de mi proyecto, ahora que veo cerca la primera versión (a falta de un problema con las urls que mapean a vistas) ya empieza a ser hora de hacerlo.

La cuestión es que Grails no tiene el comportamiento típico de include, tiene el tag render que es parecido(para el caso de un template estático sería igual) pero se orienta al principio Don't Repeat Yourself en la vista, por lo que al render hay que pasarle los objetos o colecciones de objetos que se utilizarán para renderizar el template.

Esto puede llevar a un problema de repetición de código en los controllers, por lo que aquí rompemos el Don't Repeat Yourself, siendo sensibles a futuros cambios. Ésto no quiere decir que el render no valga, en mi opinión para conseguir no repetir código dependiendo de los casos, lo mejor es combinar ambos comportamientos. Aunque el problema de la repetición de código se puede solucionar con nuestras propias librerías de tags, que con Grails son sencillas de crear, pero pienso que debería ser todavía más sencillo y limpio utilizando una acción de un controller que además podríamos reutilizar para por ejemplo peticiones XMLHttpRequest.

Metiéndonos ya en el uso del plugin, existen dos formas de hacer el include, la forma clásica con el tag includeURL:

<g:includeUrl url="/prueba/show?param=value"/>


Los posibles valores de url pueden ser tanto urls que mapean a controllers/acciones/vistas de nuestra aplicación grails, como a recursos estáticos como puede ser un html plano o un fichero de texto que se encuentren en el mismo contexto. Para el caso de las urls mapeadas, los parámetros se pueden pasar por los posibles valores de la url mapeada tipo REST como con parámetros de la request de los de siempre.

Y la segunda forma es para mi es la forma recomendada para los caso de hacer un include a acciones de nuestros controllers, includeController:

<g:includeController controller="prueba" action="show" params="[param:'value']"/>


Al que se le pasa el nombre del controller, acción y mapa de parámetros. Hay que decir que por la convención de nombres, en el caso de prueba buscará en controlador PruebaController. La recomendación es simplemente por la probabilidad mucho mayor de una cambio de mapeo de url que del nombre de un controller, cada uno verá de qué manera prefiere hacerlo ;).

Hablando ya sobre la experiencia desarrollando éste plugin, la verdad que me esperaba que fuera más sencillo de desarrollar, estaba claro que sería necesario un wrapper del response para hacer el include con el RequestDispatcher. Al final he tenido que escribir también un wrapper para el request y re-escribir parte del filtrado del mapeo de urls de grails, al ser la misma petición y no estar contemplado este comportamiento anteriormente, ha habido que hacer un poco de trabajo extra investigando el código del framework en cuanto a mapeo de urls y hacer mucho debug por no conocer el código (gracias IDEA + JetGroovy! :)).

A ver si dejo una versión estable de éste plugin en las próximas semanas, y comienzo a colaborar con el plugin de Java Content Repository para poder trabajar con ésta especificación de una forma más o menos parecida a como se usa GORM con Hibernate por debajo.

En la sesión del openjavaday sobre grails, surgió la pregunta de si se podían añadir entornos además de los que vienen por defecto: development, test y production.

Me quedé con la duda si era posible o no, convencido que eso no se les habría pasado por alto a los desarrolladores y se podría hacer de alguna forma, casualmente he tenido que hacer unas pruebas con bases de datos desde cero y no tenía ganas de andar haciendo backups de la base de datos para recuperar el estado inicial (uno que es vago :P), por lo que me venía como anillo al dedo.

En fin que, tal y como pone en la documentación, en este caso sólo he tenido que añadir al DataSource.groovy el entorno con su respectiva configuración, pero si lo necesitamos, también podemos añadir otros parámetros de configuración en el Config.groovy. Para arrancar la aplicación en nuevos entornos, deberemos ejecutar:

grails -Dgrails.env=mientorno run-app

Por ponerle una pega, estaría muy bien que fuera sólo con el nombre del entorno.