Para realizar estas validaciones he utilizado diversas técnicas, como comprobar si las variables están definidas o no, si son del tipo correcto, si los valores están entre los rangos permitidos, etc. Una de las herramientas más valiosas que hasta ayer consideraba más valiosas eran las expresiones regulares de PHP (POSIX).

Desde que comencé a utilizar estas funciones había un aviso en la documentación de PHP que me suscitaba cierta curiosidad. Este aviso decía y dice: Aviso Estas expresiones regulares no son seguras con material binario. Las Funciones PCRE lo son. Siempre me he preguntado a qué se refería la documentación con ese mensaje tan críptico, pero la verdad es que nunca pensé que pudiera afectar al uso que hacía de las expresiones regulares, no al menos en la parte de verificación de datos de formularios, información que llega en formato texto. Sin embargo, tal como dice Alex en su página, y tal como se ve también en una reciente contribución (01-04-2007, Edward Z. Yang) en la propia página de PHP, esto no es así.

PHP es uno de los lenguajes más utilizados en el desarrollo de páginas web, estimándose su penetración en alrededor de un 34% de todos los webs existentes. Esto ha sido posible dada su facilidad de uso que ha hecho que múltiples desarrolladores y empresas lo adopten como principal lenguaje de desarrollo, sin embargo, esa facilidad ha producido también que la calidad de los proyectos realizados sea muchas veces muy baja, sobretodo referente a cuestiones de seguridad como sql-injection y XSS.

Pero no todos los peligros que padecen los proyectos realizados en PHP provienen de una mal diseño o programación, sino que hay muchos de ellos que están relacionados directamente con la propia plataforma PHP. Es este tipo de fallos son los que Stefan Esser publicará cada día durante el mes de marzo, con el fin de concienciar a los desarrolladores finales de los potenciales problemas de la plataforma y forzar a los desarrolladores del lenguaje, a tomar medidas que permitan subsanar las deficiencias existentes, así como mejorar los criterios de calidad relativos a la seguridad.

En PHP4 cuando se requiere utilizar una clase es necesario haberla incluido antes en nuestra aplicación con un require o un include, indicando la ruta del archivo en la que está amalcenado. Conforme crece el tamaño de las aplicaciones es habitual que también crezca el número de clases existentes y las dependencias que hay entre los diferentes programas que forman la aplicación y ellas. Esto produce que si en algún momento necesitamos mover una clase de sitio tengamos que tocar un buen número de archivos, y casi siempre con la mala suerte de que siempre se olvida alguno que va a fallar en el momento más inesperado.

Una solución habitual suele ser centralizar en un único archivo la inclusión de todas las clases que forman la aplicación, sin embargo, normalmente en cada petición de página se suele necesitar únicamente un subconjunto de todas las clases disponibles, por lo que considero que esto es muy ineficiente, aparte de que nos obliga a hacer un mantenimiento bastante tedioso de este archivo.

La solución que suelo utilizar es disponer de una clase, de nombre ClassLoader, que me abstrae de la ubicación real de las clases y que es la encargada de incluirlas cuando se lo solicito. De esta forma, desde el código de la aplicación se le pide que se cargue una determinada clase y ella hace la inclusión real del archivo, para lo cual es necesario saber la ubicación de cada clase. En esta ocasión esta información se obtiene de forma automática a partir de unas indicaciones, para lo cual la clase realiza una búsqueda de archivos susceptibles de ser clases a partir de unas ubicaciones que hay que indicarle y almacena esta información en caché, de forma que no sea necesario realizar la búsqueda en cada petición de página.

Lamentablemente PHP, en su versión 4, no se puede considerar que sea completamente un lenguaje orientado a objetos, ya que carece de algunas características básicas como ocultación de información y sobrecarga de métodos, pero sin embargo es posible conseguir estas características con un poco de rigor. Aparte de esto, nos encontraremos con una serie de problemas, principalmente debido a la forma en que maneja las referencias, que puede hacer que nos volvamos locos en más de una ocasión si no tenemos claro cómo funcionan y no somos estrictos en su utilización.

En este artículo no voy a explicar los fundamentos de la orientación a objetos, ya que de eso ya hay multitud de libros y artículos, voy a explicar únicamente las peculiaridades que tiene PHP 4 y cómo trabajar con ellas. Comienzo explicando brevemente cómo funcionan las referencias en las asignaciones y en las llamadas a funciones y métodos, y continúo dando alguna sugerencia para conseguir la ocultación de información y la sobrecarga de métodos en las clases, finalizando el artículo con una introducción a la serialización de objetos.

Detallo a continuación los artículos que tengo previsto realizar por si alguien tiene alguna sugerencia que aportarme.

• Programación Orientada a Objetos: PHP4 no es un lenguaje orientado a objetos puro, ni mucho menos, más bien parece que la orientación a objetos se la hayan metido con calzador, pero en cualquier caso, el utilizar este paradigma permite abordar el desarrollo de aplicaciones con mayores probabilidades de éxito, sobretodo conforme incrementa su tamaño. En este artículo explicaré una serie de peculiaridades muy importantes que hay que tener en cuenta. Artículo ya publicado
• Control personalizado de errores: es posible con PHP mostrar información en los errores de forma similar a como sucede en otros lenguajes como ASP.NET o Java, mostrando el punto exacto de error y una pila de las llamadas producidas. En este artículo explicaré como realizar esto utilizando una clase a tal efecto.
• Cargador de clases: si te ha tocado programar una aplicación de tamaño medio en PHP, seguramente habrás utilizado la orientación a objetos. Uno de los problemas que tiene PHP con la orientación a objetos, es que al ser interpretado, es necesario incluir el archivo que define una clase antes de utilizarla, lo cual produce un alto acoplamiento con la ruta física en que éstas están almacenadas. En este artículo explicaré una clase que utilizo desde hace tiempo y que me permite abstraerme de este problema, permitíendome incluso reorganizar de forma completamente transparente la estructura física de carpetas en las que están almacenadas las clases.
• Sistemas de log de mensajes: una herramienta de log suele ser de mucha utilidad para la depuración de las aplicaciones, pero también para controlar el estado de una aplicación en producción. Hay diversas soluciones, desde montarnos una sencilla utilidad que escriba en un archivo, hasta la sofisticación de log4php, similar a log4j y log4net, pasando por un termino medio como PEAR::log
• Cache de datos, bloques de html y páginas web: uno de los grandes problemas de PHP, si no el mayor, aunque para algunos puede ser una ventaja, es que no mantiene el estado entre peticiones, lo cual produce que en cada petición comencemos desde cero y no podamos utilizar cosas como pools de conexiones, o tengamos que regenerar continuamente objetos que en otras tecnologías programaríamos como singletons. Una forma de minimizar esta situación es mediante la utilización de cachés. Estas cachés se pueden utilizar para guardar objetos serializados, bloques generados de html e incluso páginas enteras.
• Acceso a bases de datos: es habitual al desarrollar aplicaciones web de tamaño medio buscar cierta independencia de la base de datos, previendo futuras modificaciones o necesidades de portabilidad. La utilización de conjuntos de clases que nos abstraen de las funciones específicas de PHP nos permiten está abstracción, a la vez que nos ofrecen un marco de desarrollo orientado a objetos más o menos homogéneo con otras tecnologías. En este artículo explicaré la que a mi parecer está mejor diseñada y es más equilibrada, PEAR::DB, y explicaré también una posible adaptación específica para el tratamiento de los autoincrementales en MySQL, lo cual considero que no tiene correctamente resuelto.
• Un pequeño modelo ORM: este artículo aún no estoy muy seguro de querer embarcarme en hacerlo debido a su complejidad, pero lo comento aquí por si acaso. Al hacer aplicaciones orientadas a objetos un problema habitual es el como modelar los objetos y sus relaciones, tal como las tenemos en PHP, en una base de datos relacional. En este artículo explicaré las ventajas de utilizar un modelo de persistencia que permita afrontar la lectura, escritura y actualización de objetos de una forma homogénea y hasta cierto punto independiente del sistema de almacenamiento. En cualquier caso no pretenderá ser un completo sistema de persistencia como Hibernate o similares, dadas las limitaciones de PHP y lo complejo que sería desarrollarlo.