A principios de verano os adelanté una primera aproximación sobre lo que iba a ser Leophard, un framework para el desarrollo web con php (sí, otro más).
Pensaba que podría tener una primera versión para Septiembre pero como todo lo que puede complicarse se complica, no voy a poder alcanzar esta meta.
En parte no voy a poder alcanzarla, además de por estar hasta arriba de trabajo (no he podido tomarme ni un fin de semana de vacaciones todavía), va a ser por una serie de cambios que voy a asumir en mi forma de trabajar en general a partir de ahora.
TDD
El cambio más importante que voy a adoptar es aplicar sin excusas TDD es decir, desarrollo guiado por tests. Y lo primero que he empezado a hacer es a escribir los test sin escribir todavía una sola línea de código.
Es cierto que tenía un prototipo funcional con un sistema de enrutamiento, de vistas y controladores muy básicos ya funcionando. Sin embargo, me he dado cuenta de que ningún desarrollo y en especial un desarrollo de este tipo, debe ejecutarse sin asegurarse la calidad que te permiten obtener los test unitarios, siempre que un proyecto se plantee de esta forma desde el principio.
En teoría esto debería hacerme ir más lento al principio, pero creo que merecerá la pena para obtener una arquitectura de calidad y evitar problemas en el futuro.
Ciclos cortos de desarrollo
Cuando me puse a desglosar la complejidad de un framework de este tipo, aun queriendo hacer algo simple y ligero, las posibilidades de complicarlo para intentar cubrir posibles necesidades son difíciles de ignorar.
Por suerte cada vez tengo más control sobre mí mismo acerca de evitar ser demasiado previsor para problemas que no tocan y el objetivo principal del proyecto, que es conseguir un framework ligero y ante todo simple, me ayuda en esta meta.
Dividiré el desarrollo en fases muy cortas para evitar caer en la resolución de problemas no críticos y tener cuanto antes una versión que se pueda usar aunque no cubra todos los problemas que puedan cubrir otros frameworks como Symfony o Kohana.
Propel
Desde un principio he descartado el desarrollo de un orm propio ligero, es una auténtica locura y casi prefiero hacer un gestor de conexiones para PDO que intentar hacer un orm para el mismo.
Propel desde la versión 1.3 tiene una capa orm sobre PDO que funciona muy bien y es bastante más ligera y rápida que Doctrine2. También prefiero Propel a Doctrine2 porque lo encuentro más simple y porque al menos yo, me siento más cómodo usándolo.
De Propel hay dos cosas que no me gustan: la dependencia de Phing (que tiene los días contados) y por tanto de Pear (que lo odio) junto a que los esquemas y configuraciones se escriben en xml. Para esto último me haré una implementación para que estos xml puedan generarse desde php de forma sencilla y menos tediosa.
No obstante dejaré la puerta abierta para otras opciones.
Dudas en formularios y en la vista
Sobre la vista
Tengo una duda en la vista y es que no se por qué modelo decantarme, si por el modelo de herencia de Symfony2 o por el tipo de implementación decorator que teníamos en Symfony1.x.
Por ejemplo, en Symfony 1 teníamos un layout donde cargábamos el contenido de cada controlador en una variable llamada $sf_content. En las platillas usábamos include_component o include_partial para dividir las partes de nuestra aplicación web en la capa de vista. Por defecto la plantilla asociada a un controlador era contenida en la variable $sf_content que se incrustaba en el layout que indicásemos o se devolvía si indicábamos que esa vista no tenía layout.
En Symfony2 vemos un modelo basado en la herencia de vistas, algo que podemos encontrar en otros framework como asp.net mvc. En cada vista se indica el parent, en el que se ha definido un esqueleto de bloques, y se escribe el código html que su parent debe insertar en cada bloque.
Yo prefiero la opción que teníamos en Symfony1.x, pero no las tengo todas conmigo si este es el mejor modelo.
La vista usará la última versión de Smarty, que actualmente es el motor de plantillas más extendido y que más desarrolladores php conocen.
Sobre los formularios
Este es un tema que tengo que analizar con calma pero tengo una cosa clara: quiero que sea simple crear y validar formularios.
En la creación y validación tengo que pensar muy bien cómo hacerlo para evitar que el programador tenga que escribir mucho código o al menos tanto como en Symfony1.4.
Quiero simplificar el proceso a la hora de recibir los datos, hacer el binding y comprobar si es válido.
En symfony deberíamos hacer lo siguiente en el controlador:
- Comprobar el tipo de método http para procesar el formulario en caso de que sea POST (en el más del 90% de los casos)
- Hacer un $form->bind($array); para obtener y filtrar los datos
- Hacer un $form->isValid() para comprobar que el formulario es válido.
Yo prefiero tener algo así en un sólo paso:
- $form->validate(Request $request, $method=”post”);
Otra opción es que los formularios se validen en el mismo request de la petición, de una forma similar a como se hace con el request validation de asp.net mvc 3.
Es decir, la validación se haría en el mismo request del action del fomulario y no habría que ejecutarla de forma explícita en el controlador.
Tengo que dar unas vueltas a todo esto, sobre todo a la hora de crear los widgets y validadores.
Este será el último post de este tipo sobre Leophard que haga en este blog, intentaré montar un sitio web en las próximas semanas dedicado al proyecto.
