Posts Tagged ‘CakePHP’

ASP.NET MVC

enero 19, 2008

Anoche fui a una TechNight de Microsoft donde presentaron ASP.NET MVC. Los chicos que dieron la exposición estuvieron muy bien, y que haya habido cerveza y papas fritas a la salida me pareció un gran gesto. Eso y los ojos de una muchacha que andaba dando vueltas por ahí, azules como el cielo de este hermoso día.

Mi pregunta era como habían hecho las cosas… No las hicieron mal, solo que las hicieron igual… ¡Ejemplo del blog con comentarios incluido!

Igual a Ruby on Rails, a Monorail, a CakePHP, a todos los frameworks MVC, pero con las tecnologías de VS 2008. Como ORM utilizan LINQ, como API para Sindicación usan WCF, etc.

Algo muy positivo es que los módulos que componen el modelo se comportan como módulos realmente y son intercambiables.

Tiene un router de urls, expresiones regulares para validar. ¡Está todo!

Tal vez lo más interesante sea en que cada parte sea implementada como una interfaz, permitiendo implementar las propias, hacer mock-objects, utilizar sistemas de templates como los de MonoRail o implementar el propio sistema de Ruby On Rails. Es muy flexible en eso. Esto para integrar aplicaciones ya desarrolladas es un golazo.

Otra ventaja -que al programador asp.net medio no le parece tal- es que se van el viewstate y el postback. ASP.NET depende mucho de estas cuestiones y ahí es donde se complican la mayoría de las páginas. Haber transportado el esquema de eventos de Visual Basic a la web es algo que ayuda mucho a acortar la curva de aprendizaje para pasar de una tecnología a otra, pero los dolores de cabeza empiezan cuando hay que hacer cosas en AJAX, o necesitamos manosear el DOM desde javascript. Se puede calcular o directamente obtener el id del DOM de los controles. El drama es cuando estos son generados como ItemTemplates, hay que hacer alguna chanchada. El esquema es bueno en una aplicación de escritorio, pero en web es muy pesado. Esto lleva a que todos los controles que dependían del viewstate y del post-back hayan quedado, bueno, “deprecated”. Tendrían que haber visto como se puso la monada cuando los chicos tuvieron que avisar que el GridView no iba más. AJAX.NET también se ve comprometida.

Tranquilos muchachos, están los Helpers de la UI para generar nuestros nuevos controles. En vez de Viewstate usamos el cache del lado servidor. Es programar un poco más, pero podemos armar nuestro propio Viewstate usando la Cache. Y ganamos obteniendo páginas y sesiones más livianas.

Con .NET 3.5 hay variables tipadas dinámicamente, saludando al variant de VB. Sinceramente, si no era porque las variables NO empezaban con $, hubiera jurado que estaba viendo código PHP y templates de CakePHP en Visual Studio 2008.

Otra cosa es que IIS 7 ya permite Rewrite Rules o algo por el estilo. Lo que nos permite hacer la magia de las urls amigables a la intuición del usuario y a los buscadores.

La verdad es que me parece muy bueno que ASP.NET provea la posibilidad de trabajar con MVC, al margen de que yo lo haga. Le da al desarrollador un enfoque nuevo muy útil en varios escenarios.

Espero que le den para adelante, porque se va a ganar mucho en flexibilidad y legilibidad del código. Pero tal vez lo mejor es que trabajar con MVC nos ayuda a identificar mejor los requerimientos de nuestra aplicación y trabajar en función de ellos. Después si tiene que salir en ATOM, XHTML o código morse ya es problema de la vista y sus helpers. Nosotros tenemos nuestro controlador que hace el trabajo importante.

Yo voy a seguir firme junto a PHP5, SPIP y CakePHP en trabajo independiente, dado que no tengo un IIS7, ni plata para comprar un módulo ISAPI de redirección para IIS6 (otra cosita que tuvieron que contar los chicos), pero ASP.NET MVC sería mi “weapon of choice” a la hora de trabajar en web con .NET.

JsCalendar Helper para CakePHP

agosto 26, 2007

Necesitaba incluir el JsCalendar y me puse a buscar si estaba implementado el Helper, pero no. Lo más parecido era un controlador que se puede ver en este link.

No está nada mal, pero me resultaba un poco molesto tener que usarlo como controlador. Además el propio Pierpaolo invita a que lo mejoremos.

Yo decidí encararlo como Helper y que a la hora de imprimir el calendario en la vista sea lo más general posible.

El primer problema que se me presentó fue el de incluir los archivos .js y .css. Como estoy trabajando con 1.1.16.5421 necesitaba incluirlos en el layout. Googleando encontré que alguien ya había hecho algo para resolver este problema aquí. Hay que tocar el layout pero esto provee un Helper bastante bonito para lo que necesitaba.

Resuelto esto ya podía armar el Helper.

Tomé la clase PHP que viene con la distribución del JsCalendar. adapté el constructor al esquema de CakePHP. Desde el constructor se selecciona el look, el idioma, el directorio relativo a js, css e img de CakePHP. A su vez se setean otras opciones por defecto. Además tuve que agregar dos parámetros. Uno ‘align’=>”, porque con MSIE salía por cualquier lado. El otro es ‘width’=>’240px’ porque el ancho iba hasta el borde derecho de la pantalla.

El método de carga de los scripts fue modificado para trabajar con HeadHelper.

Por último modifiqué “make_input_field” para que funcione con un input, una image y un link del HtmlHelper. También valida que no se haya invocado el método de carga mediante una variable de instancia. Con eso ya tenía el calendario funcionando como un helper.

¿Cómo lo uso? Cargo el helper en el controlador con la variable $helpers.

<?php
echo $jsCalendar->make_input_field( 'Proyecto/inicio', #tagName del input
array(), #opciones del calendario(*)
array(
'name'=>'data[Proyecto][inicio]', #campo
'value'=>$html->tagValue('Proyecto/inicio' ) #valor inicial
); ?>

(*) se puede ver la documentación del jsCalendar.

No hace falta usar tantas líneas, la idea es usarlo como cualquier otro widget de Html.

Los scripts js del calendario se deben poner en webroot/js/calendar/. Los css en webroot/css/calendar/ y las imágenes en webroot/img/calendar/. En caso de usar Skins deben estar los archivos distribuidos en los directorios de los css y las imágenes.

Se puede descargar el helper con el esquema de directorios.

Bueno, espero que sea útil como me resultó a mí y si quieren mejorarlo, bienvenidos sean.

Problema con acentos, ñs y CakePHP

agosto 17, 2007

Haciendo pruebas con una aplicación que tengo para proyectos, encontré que cuando cargo acentos, ñs u otros caracteres latinos CakePHP me cortaba las cadenas a partir de la primer ocurrencia del caracter “malo”.

¡Oh no! ¡Problemas de charset! Como estoy con la versión 1.1.16.x no tengo soporte de internacionalización, ni nada.

Googlear fue inútil. No encontré nada. La cuestión es que me fije la codificación del navegador y era la fatídica “Europa Occidental (Windows)”.

CakePHP usa utf-8 para comunicarse con la base de datos. A su vez presupone que se le pasan datos utf-8. Cuando el navegador mandaba los datos los mandaba en latin-1, CakePHP los procesaba como si fueran utf-8 y ahí venía el problema.

Esto pasa porque el servidor está andando sobre Windows y por defecto envía las páginas como iso-8859-1. Basta con corregir esto para que vuelva a funcionar.

¿Cómo eludir el problema sin tener que modificar el código del núcleo ni la configuración del servidor (recordar que esto no siempre está al alcance de uno)?

Agregando en el <head> de la aplicación (dir_aplicacion)/views/layouts/defaults.thtml el siguiente tag:

<meta http-equiv="Content-type" content="text/html;charset=UTF-8" />

Con eso se arregló y ya tengo mis acentos!

Saludos, y hasta la próxima.

Instalando CakePHP en public_html

agosto 3, 2007

Bueno, estoy haciendo una aplicación en CakePHP y quiero subirla a un sitio que tengo hosteado en Allytech. Como estoy teniendo problemas de configuración con ese servidor (¡no puedo acceder por SSH!) tuve que hacer mil piruetas (un script que hace el tar xvzf del archivo, después moverlos mediante el soft de control) hasta tener un orden de carpetas:

/
   /miapp               -> aplicación cake
   /cake                -> distribución cake
   /public_html         -> raíz del sitio

Según la documentación de CakePHP debía hacer los siguientes cambios en la versión 1.1.16.5421 (cambiando las cosas para mi estructura de carpetas):

//archivo: public_html/misitio/index.php
if (!defined('ROOT'))
{
define('ROOT', DS.'www'.DS.'doc'.DS.'miweb.com.ar');
}

if (!defined('APP_DIR'))
{
define ('APP_DIR', 'miapp');
}

if (!defined('CAKE_CORE_INCLUDE_PATH'))
{
define('CAKE_CORE_INCLUDE_PATH',
DS.'www'.DS.'doc'.DS.'miweb.com.ar'.DS.'cake');
}

Esto funcionaba, pero me mostraba un warning:

Warning: file_exists() [function.file-exists]: open_basedir restriction in effect. File(/www/docs/miweb.com.ar/lib//cake/libs/view/templates/errors/home.thtml) is not within the allowed path(s): (/www/docs/miweb.com.ar/) in /www/docs/miweb.com.ar/cake/cake/basics.php on line 1077

¡Me quiero volver chango!

Busqué en google y por errores similares recomendaban apagar los warning. Lujo que no me podía dar porque estaba en desarrollo.

El problema surgía de buscar en el directorio /www/docs/miweb.com.ar/lib/, que era el ‘include_path’ configurado por el hosting. Entonces me dije, saquemos eso y veamos qué pasa. ¡El warning desapareció!

Pero había que tocar el código, cosa que me parecía monstruosa. Además, ¿qué pasaba si yo usaba ese directorio para guardar bibliotecas de mi sitio?

Lo volví a poner, pero en otro orden. De vuelta el warning.

Me puse a hacer otra cosa y se me pasó el día. Después de unas horas vuelvo. Esta vez pruebo crear un directorio /www/docs/miweb.com.ar/lib/. ¡El warning ya no está más!

La moraleja es que si estamos instalando CakePHP y en “include_path” tenemos una ruta que no existe(en este caso la referenciamos “gracias” al hosting) mejor que la volemos porque vamos a tener ese bonito warning. Y si no la podemos volar, ya que yo no tengo acceso al php.ini, creemos el directorio y todos contentos.

Curioso lo sensible que se puede poner esto. Ahora voy a seguir con mi pequeña aplicación.

Gracias, vuelvan prontos

CakePHP: Bake y ACL

julio 7, 2007

Siguiendo con CakePHP me encontré con una serie de tutorials muy interesantes que se pueden seguir acá registrándote o bien por acá si no querés registrarte en otro sitio más. El último link es a un sitio llamado scribd que merece de por sí solo un post. De entrada podemos decir que se propone ser la biblioteca abierta de documentos más grande del mundo.

Habiendo corregido el tema de scaffold, pude seguir haciendo pruebas y cada vez me gusta más. Pero como bien indica la documentación, el scaffold (andamios) no son más que eso, andamios. Son una base para ir haciendo algo y después ir extendiendo uno y dándole a la aplicación el uso original para el que estaba diseñada. Sin embargo es un buen andamiaje para la obra.

Es posible “exportar” el código del sacffold mediante una herramienta de línea de comandos llamada Bake. Esta se encuentra en cake/scripts/bake.php. Se pueden exportar los modelos, las vistas y el controlador. De esta manera ya tenemos el esqueleto de la aplicación con su index (listado) y un abm. Ahí podemos modificar las views al estilo y funcionalidad que queramos. Hay que tener cuidado de no sobreescribir el trabajo que hayamos hecho en los controladores, por eso es recomenrable hacer primero esta exportación y después trabajar sobre los controladores particulares de nuestra aplicación.

Contento ya con esto, vi otra funcionalidad: las Access Control Lists (ACL o listas de control de acceso) que nos ofrecen un modelo de control de acceso a objetos. La idea es sencilla: por un lado tenemos objetos (usuarios y grupos de acceso) que quieren acceder a otros objetos(artículos, productos, cualquier cosa que queremos regular su acceso). A estos que quieren acceder se los llama ARO u Access Request Objects. Es posible también definir una estructura de arbol que nos permite crear grupos de acceso. A los objetos a los que se quiere acceder se los llama ACO u Access Control Objects. Con estas dos entidades podemos definir un sistema de control de acceso asociando los ARO con los ACO. Esta es una relación muchos a muchos y permite hasta agregar niveles de acceso a determinadas funciones (read, update, create y delete) .

Para el que siga el tutorial de IBM, con la versión 1.1.15.5144 tuve los siguientes problemas:

  • En el código del form de registro de usuarios el tutorial usa para verificar que se haya envíado el form un if y la condición es : (!empty($this->params[‘form’])) y también intenta grabar el objeto con $this->params[‘form’]. Eso no me anduvo. Reemplazando en todos los casos eso por $this->data la cosa sale como trompada de loco.
  • Cuando quise dar de alta los ARO con la herramienta de línea de comandophp acl.php create aro 1 null Users

    sale un error. Esto se corrige reemplazando el null por 0. No es lo más elegante pero funciona. Ya que no debería haber referencia a un item 0.

    php acl.php create aro 1 0 Users

Bueno, con esas dos salvedades, el tutorial es muy recomendable. Hasta la próxima.

CakePHP y django

julio 6, 2007

Estoy haciendo las primeras pruebas con CakePHP y viene bastante bien. Si bien muchas cosas ya las había visto en django, CakePHP no tiene nada que envidiarle.

Ambos son dos frameworks basados en MVC. Al parecer ambos muy parecidos a Rails, aunque todavía no he tenido el gusto de jugar con este.
MVC significa, muy por arriba, Modelo Vista Controlador. Si bien django se declara MTV, variante Modelo Template View, la idea es muy similar.

Ambos manejan Modelo como un ORM. Respecto al Modelo CakePHP se basa en extender una clase llamada AppModel que nos provee las funcionalidades CRUD. Esto es similar a los Models de django que heredan de models.Model. Lo más cómodo de CakePHP es que interpreta solo las tablas de la base de datos, si seguimos cierta nomenclatura. También me gusta más la manera que se definen las relaciones. Por otra parte, django tenía las factories de campos y generaba las tablas a partir de cómo había armado el “Modelo”. No digo que una cosa sea mejor que la otra, digo que me gusta más trabajar así.

Los controladores ya no tan son parecidos. Los controladores de django las “views” eran funciones que recibían el request y los parámetros. Para que estos views funcionaran había que asociarlos con una regla de rewrite (idénticas a las de Apache), requería definir a mano un dispatcher (siempre que no se usen genéricos). Estos retornaban un review e indicaban el template al que se asociaban. En CakePHP por cada modelo tengo que definir una clase que hereda de una clase AppController. Definiendo un método para esta clase ya tengo hecho el despacho. Estos métodos se llaman actions.

Las vistas son tal vez el punto más divergente. Es que django tiene su propio sistema de Templates (o Maquetación). Este era un poco extraño al principio, pero con un par de pruebas se terminaba manejando. CakePHP tiene un sistema de Templates que es medio un no-sistema de templates: son tags php los cuales utilizan variables y objetos que se le pasan desde el controlador. No es que en django no pase algo similar, sino que esto es casi como programar los templates en php. En esto me recuerda bastante a este artículo donde se charla acerca de la utilidad de los templates. Así que no hay nada raro en el sistema de templates, los tags y los foreach para iterar listas.

Lo que se extraña es el admin de django. Y estoy medio frustrado porque todavía no pude hacer andar los scaffolds (andamios). Al parecer son como los generics views de django.

Otra cosa que me gusta más de django es el concepto de aplicación bien esquematizado por directorios namespaces. Y de ahí vienen las ventajas de django de estar basado en python que es mucho más elegante como lenguaje orientado a objetos que php. CakePHP utiliza un árbol de directorios donde guardo las vistas en un directorio, los modelos en otro y los controladores en otro más. Si bien hay maneras de separar, esta todo apilado.

Pero irónicamente, la fortaleza de CakePHP es estar desarrollado en php. Y encima compatible con php4 y php5. No voy a entrar en la gran discusión acerca de las ventajas y las limitaciones de php y su relación con los objetos.

Acá en Argentina es mucho más sencillo encontrar hostings que soporten php que python. De hecho prácticamente todos soportan php. El despliegue de django en cambio requiere modificar la configuración de Apache y cargar un módulo más, cosa que pone los pelos de punta de los proveedores de hostings.

Y a nivel global, php sigue siendo el lenguaje web más extendido, no sé si por su flexibilidad o su sencillez, pero creo que tiene mucho que ver la gran comunidad que lo respalda y trabaja con él. La documentación es amplia, todo lo que te puede pasar ya le pasó a alguien. En eso CakePHP me parece que tiene mucho campo para crecer.