15. Comportamientos (o behaviors) en CakePHP. Comportamiento árbol (1).

El comportamiento árbol y las ACL

Estoy en un proyecto en que algo más adelante surgirá probablemente la necesidad de clasificar y presentar el contenido del sitio web en función del tipo de usuario. Para hacer esto, CakePHP viene con el comportamiento ACL (Access Control List, o lista de control de acceso, es un concepto informático que se utiliza para separar privilegios y determinar permisos de acceso). Por cierto, un apunte de última hora: a raíz de este hilo sobre este tema en el grupo Google CakePHP en español me acabo de enterar que IMHO quiere decir In my honest opinion; también puede ser que las ACL no sean necesarias para esto.

Navegando por Internet, y leyendo un poquito sobre este tema, he descubierto que CakePHP 1.2 incorpora cuatro comportamientos o behaviors: ACL, Containable, Translate y Tree. Como resulta que no puedo ir directamente al comportamiento ACL porque es un poco complicado y utiliza Tree, que es más sencillo, he hecho algunas pruebas con este último. Básicamente, en este post pongo en práctica la explicación del manual oficial de CakePHP, que está muy bien.

¿Qué es un comportamiento?

Hasta ahora nunca hemos hablado de los comportamientos y vamos a presentarlos. Del mismo modo que los componentes extienden la funcionalidad de los controladores y los ayudantes extienden la de las vistas, los comportamientos de CakePHP sirven para extender la funcionalidad de los modelos (recordemos que un modelo CakePHP es una clase ActiveRecord que representa una tabla de la base de datos con todo el código PHP para acceder, añadir, modificar y borrar los registros de ésta). El manual de CakePHP los define muy bien: “Los comportamientos son una manera de organizar parte de la funcionalidad definida en los modelos de CakePHP”.

El comportamiento árbol

El comportamiento árbol -o Tree behavior– sirve, por ejemplo, para montar una jerarquía de categorías. Para poder utilizar esta funcionalidad de CakePHP sólo tenemos que añadir tres campos extra a la tabla de la base de datos: padre_id, izquierdo y derecho. Más concretamente, el SQL para la tabla es este:


create table categorias(

id integer(10) unsigned not null auto_increment,

padre_id integer(10) default null,

izquierdo integer(10) default null,

derecho integer(10) default null,

nombre varchar(255) default ' ',

primary key(id)

);

Continuará…

Anuncios

14. Hacia las ACL: más sobre ActiveRecord y CakePHP

Dentro de poco empiezo con las listas de control de acceso de CakePHP y creo que la mejor forma de hacerlo (aunque me temo que antes tengo que pasar por los behaviors) es con la explicación del manual oficial y reescribiendo el post anterior, 13. ActiveRecord en CakePHP y ORM. Me estoy preparando psicológicamente porque, por algunas impresiones que he podido recoger, las listas de control de acceso son de lo más complicado que hay en CakePHP.

Ha pasado un tiempo y he asimilado mejor los conceptos gracias al libro CakePHP Application Development, de Ahsanul Bari y Anupom Syam, editado por PACKT. En realidad, no sé si el tiempo ha hecho que entienda mejor el funcionamiento de los patrones de diseño de software, o son las explicaciones que hacen Ahsanul Bari y Anupom Syam. Yo creo que se trata de esto último; en la página 6 del primer capítulo presentan los patrones de diseño de software en CakePHP así:

“Un patrón de diseño es una solución general a un problema común del desarrollo web. Un patrón de diseño no es un código completo; más bien es una descripción de la solución de un problema, que además puede reutilizarse en situaciones diferentes. En el desarrollo web hay muchos patrones de diseño que se utilizan para solucionar problemas repetitivos y comunes. CakePHP integra muchos de estos patrones de diseño: ActiveRecord, Association Data Mapping, Front Controller y MVC”.

Es decir, lo que a mí me hubiera gustado escribir (y no acababa de entender) en 13. ActiveRecord en CakePHP y ORM: “Con la capa de abstracción de Cake, ya no necesitamos escribir consultas SQL para recuperar o modificar los datos; llamando a las funciones apropiadas del modelo podremos acceder fácilmente a los datos.” 

librocake

Más adelante, en el capítulo 5, Models: Accessing Data, definen los modelos CakePHP como implementaciones PHP del popular patrón de diseño ActiveRecord; también dicen que los modelos CakePHP son mucho más que simples capas de abstracción de la base de datos. Resumiendo, y personalmente, todas las explicaciones, en general, me gustan mucho.

Es una pena que en CakePHP Application Development no se profundice en el funcionamiento de las ACL. De todas formas, no pasa nada porque he apuntado estos dos recursos para las lisas de control de acceso: la explicación del manual oficial y el capítulo 8 del libro Practical CakePHP Projects, editado por Appress. A ver si en futuros posts puedo reflejar algún avance sobre este oscuro tema de CakePHP.

2. En busca de… ¡Una web para hacer un mini estudio de accesibilidad!

Al final he pensado que puede ser más divertido hacer un mini estudio de accesibilidad a partir de una página web que puedes proponer tú. Si te gusta esta idea, deja un comentario con un enlace a tu página y vemos cómo aplicar una pequeña y rápida metodología para ver qué tan accesible es.

Playing for change

* Este vídeo es del movimiento multimedia Playing for Change, creado para inspirar, conectar y traer la paz al mundo a través de la música. Puedes verlo en http://playingforchange.com/. ¡Feliz 2009!, que sea un año mucho mejor para todos.

1. W3C y WAI. ¡WCAG!

Un momento… ¡Espera y no hagas clic en Atrás! Aunque no lo parezca, no se me ha trabado la lengua y tampoco te estoy insultando en finlandés, estimado visitante. Si no lo conoces, este post tiene como objetivo presentarte el WCAG.  ¿Cómo se pronunciará? 

WCAG, o Web Content Accessibility Guidelines 1.0, es un documento escrito en 1999 por el WAI (Web Accessibility Initiative) que  explica cómo hacer accesibles los contenidos de la Web a personas con discapacidad. La traducción al español de este documento es Pautas de Accesibilidad al Contenido en la Web 1.0.

Los catorce principios de diseño accesible del WCAG tienen en cuenta los diferentes contextos en que los usuarios pueden encontrarse en el momento de acceder a una página web. Curiosamente, estas pautas existen desde 1999, pero no ha sido hasta hace poco que han empezado a despertar el interés de los desarrolladores.

Te invito, pues, estimado visitante, a leer el documento WCAG en español, Pautas de Accesibilidad al Contenido en la Web 1.0, para que podamos seguir cómodamente el próximo post de esta categoría. El siguiente artículo es un ejercicio práctico donde veremos qué herramientas utilizar, y cómo, para hacer más accesible una página web. Aunque nosotros seguiremos el WCAG 1.0, estos días el W3C  ha publicado el WCAG 2.0, disponible aquí en inglés.

24 de diciembre de 2008. Amaya y www.mclibre.org

Estos días, a raíz de un mensaje publicado en el grupo Google CakePHP en español, he consultado varios recursos que tratan los temas de la accesibilidad y la usabilidad Web y he tomado algunas notas. Hasta hace poco he trabajado manualmente con mis vistas CakePHP, pero ahora voy a probar con el programa Amaya 11, del W3C (World Wide Web Consortium).

No he hecho muchas pruebas, pero tengo la sensación de que se trata de un acierto y proporciona un marco estupendo para el seguimiento de las recomendaciones del W3C. Además, he descubierto www.mclibre.org y este recurso excelente que explica cómo empezar con Amaya.

¿Conoces este programa? Si es así, ¡deja aquí algún comentario! ¿Qué tal es? Yo voy a empezar a seguir el curso de páginas web con Amaya; promete, y seguro que mis vistas CakePHP se hacen más usables y accesibles.

Geocodificación con PHP y el API Google Maps (3)

Autor: Quentin Zervaas

Fuente original: http://www.phpriot.com/articles/google-maps-geocoding/3

Realizar una petición al geocodificador

Cuando realizamos una petición al geocodificador podemos especificar qué tipo de salida queremos utilizar. Las opciones disponibles son: JSON, XML, KML y CSV. En este artículo manejamos datos XML.

Nota: KML (Keyhole Markup Data) es un formato XML que se desarrolló para utilizarse con Google Earth. Las salidas KML y XML del geocodificador son idénticas; sin embargo, el tipo MIME HTTP es diferente.

Aunque los datos JSON se utilizan típicamente dentro del código JavaScript, podemos usarlos fácilmente en vez de la respuesta XML;  para convertir los datos en una matriz PHP podemos utilizar la función json_decode(), disponible desde PHP 5.2.0. En este artículo usamos SimpleXML para leer los datos del geocodificador; para JSON el cambio sería trivial.

Para realizar una petición al geocodificador, se envía una petición HTTP a http://maps.google.com/maps/geo. En esta petición se tienen que especificar tres parámetros en el URI:

q es la dirección o ubicación que queremos geocodificar.

key es la clave API Google Maps que hemos creado anteriormente en este artículo.

output es el formato de salida para la respuesta. Los valores pueden ser json, xml, kml o csv.

Si queremos obtener, por ejemplo, las coordenadas de la Casa Blanca (Pennsylvania Avenue 1600, Washington DC), hacemos una petición a este URL:

http://maps.google.com/maps/geo?q=1600+pennsylvania+ave+washington+dc&output=xml&key=123456

Nota: recuerda sustituir tu propia clave API en este URL.

La dirección exacta que se envía en la cadena no es crítica; necesita datos suficientes para identificar la ubicación y no tiene que ser ambigua.

Geocodificación con PHP y el API Google Maps (2)

Autor: Quentin Zervaas

Fuente original: http://www.phpriot.com/articles/google-maps-geocoding/2

Empezar con Google Maps

Aunque en este artículo no tratamos específicamente con la visualización de mapas en sitios web, necesitamos familiarizarnos con el API Google Maps. Toda la documentación del API se encuentra en http://code.google.com/intl/es/apis/maps/index.html.

Lo primero que tenemos que hacer es crear una clave API para nuestro sitio web. Esta clave se utiliza para identificar todas las peticiones al API. La clave se obtiene de manera gratuita aceptando las condiciones e introduciendo el URL de nuestro sitio web en http://code.google.com/intl/es/apis/maps/signup.html.

En el momento de escribir este artículo, el límite en las peticiones al geocodificador es de 15.000 por día; con un poco de suerte esto es suficiente para nuestras necesidades. Como explicaremos más adelante, te animamos, cuando sea posible, a utilizar cache para los datos del geocodificador.

Una vez tenemos la clave API ya podemos acceder al geocodificador. El resto del artículo, basado en la documentación de http://code.google.com/intl/es/apis/maps/documentation/services.html, explica cómo usar el geocodificador.