Éste es un aviso para todo aquel que todavía programe en PHP4: ¡olvídalo!

Y éste es un aviso para todo aquel que tenga clientes con cosas programadas en PHP4: ¡corre a saber cuándo tu hosting migra a PHP5 o te hundes!

Me voy de vacaciones. Nos vemos en unas semanas….

Tuvimos una hecatombe en el correo que habitualmente utilizamos los programaniacos y perdí la dirección de algunos post que me serían de gran utilidad, así que por una vez y sin que sea de precedente, voy a hacer algunas afirmaciones sin que pueda dar la URL de donde las he extraído, no obstante, creo que es mejor un post un pelín amarillista que nada.

En fin, hace mucho leí un post que me paso  Luis acerca de un nuevo servidor de aplicaciones Java que no cumplía el estándar JEE. El nombre del proyecto es JavaSource y es un servidor de aplicaciones que entronca con una nueva forma de entender las aplicaciones Java. Es mucho más ágil y ligero y permite personalizar más el despliegue de aplicaciones que en los grandes servidores convencionales como WebSphere por ejemplo.

Está basado en Spring y por tanto sólo se pueden desplegar aplicaciones realizadas con este framework y copia algunas ideas de la arquitectura OSGI. Una de las grandes ventajas es que se permite desplegar una aplicación Web o un servicio Web como tal, dado que este tipo de aplicaciones tienen sus características especiales y no como antes que todo eran EJBs.

Como os imaginaréis el servidor trajo cola y los hooligans de una y otra parte tuvieron más que palabras en la blogesfera, hasta el punto que los creadores de Spring se tuvieron que pronunciar en contra de este framework y en favor de su arquitectura OSGI, que por lo que he leído, permite personalizar mucho más el despliegue de aplicaciones pero debe hacer el mismo mucho más infernal que el viejo estándar JEE. A mí, en particular, me sonó un poco corporativista ya que asegurar que esta idea era mala porque les gustaba más la suya no me suena muy serio, claro los niños de uno siempre son los más guapos.

Puede que el estándar JEE se haya quedado anticuado pero me parece que puestos a cambiarlo se debería pactar el nuevo estándar en la comunidad Java y no dejar que cada uno despliegue aplicaciones como le de la gana porque eso si que puede llevar al caos.

Os dejo la dirección dónde se habla de este framework y me gustaría que los que lo hayáis utilizado dejéis vuestras impresiones, si no lo habéis utilizado y queréis hacer una crítica constructiva también me gustaría leerla.

http://www.springsource.com/products/suite/applicationplatform

Es usar las mejores prácticas para programar en PHP es estrictamente necesario, con más o menos matices, y Zend Framework te ayuda a hacerlo aunque no tengas ni idea de lo que haces.

La verdad es que no he encontrado mucha información sobre ellos en internet. Me quedo con la página de Scala donde explican su implementación.

Lecturas:

• Ventajas de los Ruby mixing frente a Java.
• El análisis que hicimos en programanía del “efecto Ruby” sobre otros lenguajes como PHP.

Las closures son la posibilidad de pasar como argumento un trozo de código. Es una de las principales ventajas de Ruby frente a PHP y amplía enormemente las posibilidades de reutilización de código…

Parece que la publicación de PHP 5.3 va a ser un acontecimiento casi tan importante como la publicación de PHP 5.0…

Actualización:

Venkman me corrije en los comentarios (mejorando tanto la definición chorrifláutica que había puesto de closures, que lo voy a poner en el propio post):

Una “closure” es una construcción que existe en tiempo de ejecución que vincula una función con un entorno (scope) diferente -y ya cerrado- al entorno en el que se ejecuta.

Es decir, es la construcción que abarca una función (que puede ser anónima o no serlo; es decir, puede ser un “trozo de código” o no) y un entorno de resolución (scope) que está accesible para esa función pero no para el resto porque ya está “cerrado”.

Existen dos tipos:

• Los Internal DSL: están escritos en el propio lenguaje padre. Son basicamente lo que siempre hemos conocido como “API” aunque utilizando “fluent interface” y atendiendo más a la semántica de los métodos. Un ejemplo en Java sería la generación de SQL por parte de Hibernate:

SQLQuery sql = new SQLQuery();
sql.Select("Id").Select("FirstName").Select("LastName").From("Person").Where("Id = 1").Where("FirstName = 'Chris'").OrderBy("LastName").OrderBy("FirstName");
string strSqlString = sql.ToString();

• Los External DSL: No están escritos en el mismo Java. Se utiliza un lenguaje externo. En el caso de Java han triunfado especialmente los External DSL escritos en XML. Un caso sería el MVC de Struts, que se declara así:

<action-mappings >
<action path="/listar" type="org.springframework.web.struts.DelegatingActionProxy">
<forward name="listar" path="lista.aplicaciones"/>
</action>
<action path="/formularioNuevaAplicacion" type="org.springframework.web.struts.DelegatingActionProxy">
<forward name="mostrar" path="nueva.aplicacion"/>
</action>
<action path="/nuevaAyuda" attribute="aplicacionForm" name="aplicacionForm" type="org.springframework.web.struts.DelegatingActionProxy" scope="request" input="nueva.aplicacion">
<forward name="nueva" path="/listar.do"/>
</action>
</action-mappings>

El artículo cuenta cómo la experiencia ha demostrado que los DSL que realmente funcionan son los Internal, que están escritos en el propio Java. Es inviable aprender cincuenta minilenguajes externos. Además compilan y se adaptan muy bien a las estructuras existentes.

Los external en XML tuvieron mucho éxito en Java porque se resolvían en tiempo de ejecución y permitían cambiar cosas sin recompilar. En el caso de lenguajes dinámicos como PHP, Ruby, etc… esto no tiene sentido. Además los XML´s habría que cargarlos en cada request, con la recarga de servidor que supondría eso…

Gracias a Raúl por pasarme el artículo y ayudarme con los ejemplos en Java, que no es mi fuerte.

¿Hasta qué punto atendéis a la encapsulación en vuestros diseños?

Row Data Gateway
Te permite disponer de un objeto que representa directamente una fila e la base de datos. Todo el acceso a la fila queda oculto tras la interfaz de la clase. En principio, no representa mayor lógica de negocio.

Active Record
Te permite disponer de un objeto que tiene tanto la lógica de acceso a datos como la lógica de dominio.

Data Mapper
Te permite disponer de dos objetos. El primero representa la lógica de negocio. El segundo el acceso a datos. Se trata de realizar una correlación entre objetos de lógica de negocio y tablas de la base de datos.

Table Data Gateway y Row Data Gateway son los dos patrones conlos que no se realiza ningún tipo de mapeo entre la base de datos y la lógica de negocio. La principal ventaja es que te permite, escribiendo muy poco código, disponer de un acceso a base de datos limpio y bien estructurado. La desventaja es que presenta bastantes dificultades a la hora de incluir lógica de negocio y crear un auténtico Model.

Active Record y Data Mapper, en cambio, sí ofrecen la posibilidad de incluir fácilmente lógica de negocio junto con el acceso a datos. En el caso de Active Record esa lógica de negocio se mezclará con el acceso a datos en la misma clase. Si el mapeo entre las clases y las tablas de la base de datos es sencillo, será suficiente. En caso contrario, habrá que separar ambas lógicas (lógica de negocio de lógica de acceso a datos) utilizando Data Mapper.

• Tabla Data Gateway y Row Data Gateway son la opción utilizada por el Zend Framework.
• Active Record es una solución típica en Ruby on rails.
• Y Data Mapper sería propio de soluciones DAO, muy vistas en Java. En Java son populares frameworks de mapeo de clases como Hibernate.

Los Ez Components tienen muchos componentes que te ofrecen lo mismo que el Zend Framework. Pero hay unos cuantos que no:

• Ez Graph: para la generación de gráficos. Funciona muy bien, te permite bastantes formatos y los gráficos son visualmente bastante atractivos.
• Ez Database: ofrece lo mismo que las del ZF pero además puedes hacer algún tipo de ORM.
• Ez Workflow: éste me parece muy interesante. Te permite configurar flujos de trabajo (roles, documentos, estados) para implementar procesos.

Otra ventaja más del ZF: se puede combinar con Ez Components para aprovechar las ventajas de los dos y simplificar más todavía el desarrollo de aplicaciones…