Cómo hacer un framework ligero en PHP (I) – Introducción y .htaccess

Esta serie de posts pretende enseñar cómo podemos hacernos un bootstrap ligero para nuestras aplicaciones PHP que nos sirva de base sobre la cual empezar a trabajar.

Personalmente, soy partidario de no re-inventar la rueda y intentar usar convenciones y frameworks robustos y probados en mil aplicaciones. Básicamente pienso que si algo es usado, revisado y creado por muchas personas probablemente será mucho mejor que cualquier cosa que creemos solos en nuestro garaje, por muy buenos que nos creamos.

Sin embargo, también creo que está bien saber cómo funcionan estos frameworks, tanto a nivel laboratorio como para poder trabajar mejor con ellos. Últimamente hay mucha gente que programa en Zend Framework, en Symfony, o en cualquiera de los grandes pero realmente no tiene ni idea de cómo van y lo que es peor, bastante poca idea de la base de PHP.

Para mí, el bootstrap de una aplicación web debería como mínimo hacer lo siguiente:

– Tener un autoload de clases, modelos, controladores, helpers, etc basado en una convención de ficheros y directorios que podamos definirnos.
Parsear la URL según un esquema (Lo habitual suele ser algo estilo http://dominio/controlador/accion/param1/valor1/param2/valor2 aunque hay variantes) y redirigir la petición al controlador correspondiente.
Configuración de la aplicación a nivel de parámetros de PHP (y ligado con esto la gestión de entornos).
– Establecer la comunicación con la BBDD, Memcached y resto de recursos que usamos en la aplicación a partir de ficheros de configuración.
Control de sesiones (en BBDD, Memcache o nativas), especialmente en aplicaciones que comparten HTTP y HTTPS.
– Tener gestión de idiomas, ya que hoy en día es casi obligatorio en cualquier web que se precie.
Control ROBUSTO de errores y excepciones (supongo que todos hemos sufrido las carencias de PHP, especialmente en versiones anteriores y muy especialmente las herencias de malos programadores que un día decidieron hacer un framework super-molón de la muerte que nadie más podría tocar).

Es bastante interesante también tener lo siguiente:

– Usar algún sistema de plantillas como Smarty o los nuevos que lo quieren destronar como Twig (aunque PHP plano nos puede valer muchas veces).
– Control de llamadas AJAX / No AJAX / Otros mimetypes.
– Permitir usar el framework con CLI, muy útil para Unit Testing pero también en procesos que pueden durar mucho rato, como un envío masivo de mails, crons de limpieza, etc…
– Sistema fácil de añadir librerías ya existentes para tareas habituales como: tratamiento de imágenes, gestión de mails, generación de PDFs…

Como veis, hay bastantes cosas y muchas veces sale a cuenta coger algo testeado y comprobado por mucha gente.

En los próximos artículos iremos desglosando todo esto y quién sabe… ¡a lo mejor hasta queda algo digno y presentable!

Para empezar, hablaremos del archivo .htaccess. Existen muchas versiones, muchas de ellas muy profesionales, pero la base de un .htaccess para un framework PHP debería ser algo similar a esto (cogido de Kohana):

# Turn on URL rewriting
RewriteEngine On
 
# Installation directory
RewriteBase /
 
# Protect hidden files from being viewed
<Files .*>
	Order Deny,Allow
	Deny From All
</Files>
 
# Protect application and system files from being viewed
RewriteRule ^(?:application|modules|system)\b.* index.php/$0 [L]
 
# Allow any files or directories that exist to be displayed directly
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
 
# Rewrite all other URLs to index.php/URL
RewriteRule .* index.php/$0 [PT]

Con estas líneas poco inteligibles (no soy un gran experto pero podéis buscar más información en Google) básicamente le estamos diciendo a nuestro apache que si recibe una URL que pide algo inexistente en el disco, nos envíe la petición al archivo index.php que intentará tratar esa petición.

Además, en el caso de Kohana, prohibe ver las carpetas application, modules y system (donde está la base del framework) y protege también los archivos ocultos Linux (que empiezan por .)

Hoy en día todos los hostings de medio pelo permiten subir un archivo .htaccess para este fin. Si el vuestro no lo hace, sinceramente, dejad de trabajar con ellos.

Por hoy lo dejamos, el próximo día trataremos el parseo de la URL y un posible autoload!

You may also like...

4 Responses

  1. Albert Casademont says:

    Como nota a añadir a este excelente post, si tenéis la posibilidad de incluir estas líneas en el fichero de configuración de Apache en vez de htaccess mucho mejor ya que a cada petición que se recibe en el servidor, se lee y procesa el .htaccess mientras que si lo tenemos guardado en la configuración de Apache, se lee una sola vez al arrancar el servidor.

    Las ventajas e inconvenientes están claros. Cada vez que hagamos un cambio en el .htaccess, la siguiente petición web ya lo hará con los cambios. Si lo tenemos en los ficheros de configuración, habrá que reiniciar el servidor.

    Mi sugerencia final sería tener un .htaccess mientras estamos en fase de desarrollo y una vez veamos que todo va como queríamos, pasarlo al archivo de configuración.

    Obviamente, aquí deberemos disponer de un hosting dedicado/virtual, para poder hacer modificaciones en los archivos de configuración y privilegios suficientes en el sistema como para hacer un reload del Apache.

  2. Qué crack… esto es telepatía casi 😉
    Justo ayer empecé a investigar, para ciertas cositas mías, cómo hacen los frameworks para manejar, por ejemplo, instancias Singleton de DB
    Esperaremos los próximos posts, a ver cómo lo resuelves tú :mrgreen:

  3. Pere says:

    Hace unos meses creé mi propio framework que cumplía prácticamente todos los puntos que has mencionado (no usé templates), no para reinventar la rueda, sino como bien dices, a modo laboratorio para entender mejor “las entrañas” de los frameworks.

    Así que voy a estar atento a tus posts, que seguro que se me escaparon muchas cosas por el camino :)!!