aPHP - Una especie de "plantilla de aplicaciones" para PHP

[semptrion]

Hola David:

Aquí estamos otra vez para darnos una mano en lo que se pueda. He revisado (muy de pasada por cierto) el código del aphp y ya he preparado algunos comentarios.

Respecto de la idea y de la consecución de ésta, te auguro el mejor de los éxitos.

Respecto de lo solicitado por ti, estas mis observaciones, en un plano general.

Observaciones de forma:

• No se muestran convenciones en la codificación.
  • Demasiadas deficiencias en cuanto a la longitud de las líneas, tanto en los comentarios como en el propio código
  • El uso del espacio en blanco es arbitrario.
  • La identación es aleatoria.
  • No existe una regla evidente para la apertura o cierre de llaves.
• El pronunciado uso del spanglish (p.e. un método llamado AddCabecera)
• No está especificada la versión del php.
• En los comentarios no existe el versionamiento (aunque la documentación muestra reglas claras y ha sido cuidadosamente elaborada, supongo que para utilizar phpDocumentor)
• Uso indistinto de comillas y apóstrofes para contantes literales.

Observaciones de fondo:

• (Diseño) La profunda dependencia con la estructura del sistema de archivos (p.e. header('Location: ../')) hace que necesariamiente el archivo se encuentre dependiente del directorio raíz en el entorno web!
• (Diseño) El manejo de errores es espontáneo y no sigue la codificación de errores del protocolo (http 1.0 ó http 1.1)
• (Seguridad) La salida de los programas es indefinida. Se utiliza la cláusula exit y debería(?) utilizarse die. Si es que el programa nada más hará.
• (Diseño) Existe una mezcla entre el código php y el código html
• (Diseño) Existe una dependencia de los atributos en el código html generado desde el php (p.e. captcha.class.php líneas 86 a 91)
• (Seguridad) Existe una separación entre los archivos de constantes de una clase y de la clase que usa esas constantes.
• (Diseño) Dependencia del motor de base de datos mysql (p.e LIMIT en consultas.inc.php)
• (Seguridad) Uso de cookies para la autenticación
• (Seguridad) Definición del modo desarrollo y modo producción mediante artilugios como saber si el servidor es localhost.
• (Diseño/Seguridad) La arbitrariedad en el uso de variables globales
• (Funcionamiento) No existe la posibilidad de portalizar las aplicaciones ni siquiera de incluirlas dentro de otras.
• (Seguridad) No existe la posibilidad de generar roles o diferentes niveles de acceso.
• (Seguridad) La configuración del archivo .htaccess puede tener resultados imprevistos en Windows, ya que usa cláusulas para linux (p.e. enlaces simbólicos). Habría que definir qué es lo que hace cada línea introducida en el .htaccess.
• (Seguridad) El archivo de configuración define parámetros, pero no especifica funcionamiento.

Al realizar las observaciones precedentes, no he pretendido revisar la lógica de los métodos (ni el diseño de las clases), sino empezar por algunas líneas base que permitirían el crecimiento del software y, por supuesto, su uso.

Entre las observaciones generales, quiero resaltar el tema de la construcción del código en sí. Si bien existe mucha preocupación por la documentacion, no encuentro preocupación por el mantenimiento del código; es decir, no se ven convenciones en la codificación que puedan ser utilizadas por otros programadores o por robots. En el tiempo, será más fácil reemplazar el código que entenderlo.

Esta situación se agrava por la mezcla entre el código php y el código html (y el código css y el código javascript) y el despliegue "inmediato" y oportunista. Si es invocado un método, éste desplegará datos, aún cuando luego deban ser (recién) enviados los encabezados.

Definir si los errores deben ser mostrados dependiendo de si es localhost resulta muy doméstico. Es mejor pensar en un modo de desarrollo y otro de producción, donde el modo es un estado del sistema y no una condición ni una situación.

La configuración establece los parámetros de funcionamiento del sistema, pero como un ente aislado de la propia configuracion del php, del apache y del sistema operativo. Así, el tema de la codificación, de la región o del magic quotes pueden afectar al funcionamiento, porque "variaron de lo que pensábamos", lo que resulta inadmisible en términos de un lanzador de aplicaciones o plantilla de aplicaciones.

Ahora, los demás temas (incluyendo el de la licencia Affero GPL o el del tema de las cookies) son totalmente tuyos y será una decisión que deberás cargar el resto del proyecto.

Sin embargo, creo que deberías revisar más el asunto de la reutilización de código que, de mejor manera (y con mejor licencia GPL) ha encarado temas como el manejo de mail. Te recomiendo des un paseo por http://pear.php.net o por http://pecl.php.net/ y que también revises http://framework.zend.com/

Para las convenciones, puedes adoptar alguna (como la de PEAR) o tomar ideas de otras (p.e. http://java.sun.com/docs/codeconv/).

Me siento inclinado a aplaudir el hecho que hayas previsto la posibilidad de tener una aplicación multiidioma; creo que estás en el momento de pensar en temas como el de la zona horaria y diferentes codificaciones (actualmente usas utf-8 para todo).

Finalmente, rescatar el hecho que tu código está en nuestro idioma. Sin embargo, EN LA MAYORÏA de los temas específicos ya se han hecho esfuerzos mucho más productivos (PEAR, PECL) que, si bien han producido comandos, éstos son como comandos con esteroides sin ton ni son. Ahí es donde tu concurso y esfuerzo puede ser mucho más enriquecedor: en establecer las reglas del juego para una plantilla de aplicaciones y su mejor empleo.

Saludos.