viernes, 12 de septiembre de 2008
El nuevo navegador de Google es incompatible con Google Groups
sábado, 30 de agosto de 2008
ORM: Mapeo de herencia a multiples tablas
Estudiando el tema, tiene dos puntos bien importantes, la generación del esquema y como son pedidos los datos a la base. En primer lugar, la generación del esquema debe tener reglas que permitan saber cuando una clase se debe mapear a la misma tabla que su superclase o a una tabla distinta, para esto decidimos usar el atributo "withTable" con el que cuentan todas las clases persistentes, de este modo si una subclase define este atributo en un valor distinto al de alguna superclase, automáticamente se toma como que para esa clase (y sus subclases que sigan las mismas reglas) se genere una nueva tabla.
Por otro lado, para obtener datos de la base, como una instancia de una clase puede estar dividida entre varias tablas, debe haber algún mecanismo que permita hacer joins entre las tablas para reconstruir el registro completo, y así levantar toda la información de una instancia de una determinada clase. Para esto se inyecta un nuevo atributo "super_id" que es una foreign key a la tabla que mapee las superclases de la clase que se quiere cargar, y el join se hace por ese atributo con el identificador en la tabla de las superclases. Esto es medio complicado de explicar pero va a ser muy simple de utilizar, más que simple, va a ser transparente al usuario, ya que toda la responsabilidad de cargar la información correctamente corre por parte del framework.
Como se mencionaba antes, esta característica da más flexibilidad a la hora de resolver un problema, por ejemplo en el caso de tener muchas clases que heredan de una sola, en el caso de mapeo de una sola tabla la cantidad de columnas de la misma sería muy alta, y se podría "dividir" el problema mapeando algunas clases en otras tablas y dejando que las clases más utilizadas se sigan mapeando en la misma tabla que la superclase (para que sea más rápida la carga por no tener que hacer joins).
Esperamos tener esta caracteristica funcionando para la semana que viene y con suerte también tendremos la liberación de la próxima versión del framework.
viernes, 15 de agosto de 2008
Visión a futuro
Ahora bien, ¿qué tenemos?, tenemos un framework con una implementación completa del patrón MVC, tenemos una implementación completa de un primo lejano del patrón Active Record, tenemos generación automática de las tablas de la base de datos, tenemos integración con 2 motores de bases de datos (MySQL y SQLite), tenemos convenciones que, si se siguen, nos simplifican la vida (que poner, donde ponerlo, como llamarlo, etc), tenemos una forma sencilla de definir controladores, tenemos una forma sencilla de definir las vistas, tenemos helpers que nos ayudan a generar vistas, tenemos soporte de templates que nos ayudan a reutilizar código entre vistas (páginas), tenemos soporte para layout que son simplifica el tema de definir un mismo formato general para un conjunto de páginas y poder actualizarlo y mantenerlo de forma sencilla, tenemos soporte completo para i18n (una gran cosa), tenemos una primer integración con AJAX (la parte de llamadas no de efectos y animaciones), tenemos soporte para custom mappings, que son mapeos de las urls que nos dejan apuntar al controlador y acción que querramos, tenemos soporte para filtros de acciones que permiten ejecutar una serie de funciones, definidas por el usuario, antes y después de ejecutar la acción del controlador, en fin, tenemos un lindo framework, pero eso no alcanza, además recién estamos en 0.1.4, y mi visión es que recién en v0.2.0 se va a llegar a un framework completo con el cual se pueda desarrollar cualquier sistema y ponerlo en producción.
Ahora el trabajo estará concentrado en ampliar los helpers, completar la integración con AJAX para llamadas y procesamiento de respuestas JSON, integrar algún otro motor de bases de datos (tenemos a PostgreSQL en la mira), seguir mejorando y estandarizando la API y corrigiendo bugs conocidos y que encontremos. Además trabajaremos en terminar la definición de componentes, concepto importante dentro del sistema, para que el día de mañana se puedan desarrollar componentes e instalar en sistemas Yupp que estén en producción, de forma sencilla, lo que permitiría poder encarar proyectos de mediano y gran porte en distintas etapas, dejando en cada una un sistema 100%, y agregando funcionalidad en distintas etapas. Para la versión 0.3.0 del framework buscaremos proponer un proceso de desarrollo con Yupp Framework PHP que intentará definir las etapas básicas del desarrollo, orientado al framework, señalando mejores prácticas y orientando al desarrollador, de forma de hacer el proceso lo más rápido y bien posible. Ya hablaremos más de esta parte en el futuro.
Noticia: hay nueva documentación en el sitio sobre Yupp Framework PHP, dejo el link: http://www.simplewebportal.net/yupp_framework_php_doc/
Gracias por leer,
Pablo.
domingo, 10 de agosto de 2008
Tenemos nueva versión! Yupp Framework v0.1.4
Por descargar e informe de cambios de la versión ver: http://www.simplewebportal.net/host/1022.htm
sábado, 9 de agosto de 2008
Nueva documentación disponible
Seguimos trabajando en la doc y en la liberación v0.1.4 que esperamos tener pronta mañana.
lunes, 4 de agosto de 2008
Nueva versión 0.1.3!!!
Los cambios en esta versión son:
1. Soporte para layouts. Como demo, hay un layout definido para el componente blog y la vista list de entradaBlog incluye ese layout. El layout muestra una barra con selección de idioma del blog.
2. Moficación a la forma en que se verifican los mappings de ruteo en routing.Mapping.
3. Se agregó una operación toJSON para las clases del modelo, no está completa.
4. Se agregó soporte para SQLite, para configurar que dbms se usa hay que modificar la información en YuppConfig.
En cuanto a JSON, todavía falta un poco para generar un JSON completo de todo el modelo.
Por mas info:
Descargas: http://www.simplewebportal.net/host/1022.htm
martes, 15 de julio de 2008
Soporte para layouts
El soporte para layouts es una característica bien importante para cualquier framework MVC y Yupp Framework no se podría quedar atrás, así que empecé a buscar información sobre implementación de layouts, patrones de diseño, y frameworks especializados en layouts y templates.
Un sistema de layout ayuda a ahorrar código en las vistas, de forma que varias vistas puedan compartir código común que está en un único archivo externo.
En un momento, luego de leer un rato sobre las posibles formas de implementarlo, más algunas ideas que tenía en mente, probé una pequeña implementación de un sistema de layout, y luego de un par de horas (y para mi sorpresa) lo teníaandando integrado con el framework. En este post mostraré como es que se utilizaría esta implementación de layouts.
La idea principal era no tener que modificar demasiado las vistas de forma que las vistas ya creadas sigan funcionando bien aunque no tengan referencia a un layout. Por lo tanto inventé una tag que sirve para crear la referencia desde una vista:
<layout name="blog" />
Esta tag debe ser incluída luego de <html> y antes de <head>,
para hacer más clara la referencia y más fácil de implementar el procesamiento de esa tag.
El procesamiento debía ser muy rápido y casi no afectar la velocidad de procesamiento actual, de esta forma probé hacer un procesamiento de layout mediante expresiones regulares y mediante operaciones con strings, y la velocidad con las operaciones con strings fue muchísimo mejor que con expresiones regulares, y muchísimo mejor me refiero a varios órdenes por debajo:
velocidad con operaciones de strings promedio: 5.5E-5 ms
El layout tiene la estructura de una vista pero no hace referencia al modelo y tiene dos variables disponibles para poder mostrar el contenido de la vista de la cual es layout, estas son $head y $body, que representan el contenido del <head> y del <body> de la vista.
Este es un ejemplo de un layout:
<html>
<head>
<style type="text/css">
...
</style>
<?php echo $head; ?>
</head>
<body>
<div style="padding:10px; background-color:#6af;" align="right">
<?php echo h('locale_chooser'); ?>
</div>
<div style="padding:10px;">
<?php echo $body; ?>
</div>
</body>
</html>
Por último quien hace el proceso de la vista es una clase llamada LayoutManager que se
encarga de resolver referencias a layouts y mostrar la vista generada. Si la vista no contiene una referencia a un layout, simplemente muestra la vista igual que antes.
Si bien esta solución funciona bien, se puede mejorar en varios aspectos:
- Chequeos de errores, para hacerlo más robusto.
- Más flexible, por ejemplo poder acceder a más información de la vista como el título, ahora solo se accede al head y al body.
- Poder incluir N niveles de layouts en cascada, podría servir para que un layout a su vez pueda tener un layout que
lo contiene y poder definir distintas secciones de la página que se arma en distintas layouts.