Taberna del Turco

El presente texto trata de exponer una idea que se podría plasmar en una combinación de metodología y librería para PHP que ayuda a gestionar las típicas acciones de una entidad en el sistema que estemos modelizando. Con entidades me refiero a los típicos elementos sobre los que hay que trabajar con la base de datos y requieren el típico Crear-Modificar-Borrar-Listar: editor, usuario, producto, etc.

La idea es utilizar la misma filosofía que hay tras el scaffold de Ruby on Rails, en la que se crean automáticamente funciones para el alta, baja, modificación y listado de entidades (ver Scaffold y Tutorial Scaffolding). Además, se evita cualquier código relacionado con formularios, validar datos y demás, ya lo hace el framework por sí mismo.

El funcionamiento sería el siguiente: cada entidad (habría que determinar qué entendemos por entidad) tiene asociado un fichero action_entidad.php, así, cada acción relacionada con dicha entidad (un alta en la base de datos, un formulario de login que requiera consultar login y password,…) pasará por dicho fichero. Dicho fichero realizará todas las validaciones de datos: en caso de haber error mostrará el mensaje apropiado, y en caso de haber un acierto hará un echo de una página que redireccione a la página destino. El esquema es el siguiente:

donde a:login se refiere a que se lleva a cabo una acción de login y r:… se refiere a si el resultado a sido OK o ha habido algún error.

Vamos al ejemplo directamente: imaginemos que en nuestra aplicación tenemos editores y tenemos que trabajar con ellos. Necesitaremos las típicas funciones: alta_editor(), baja_editor(), modificar_editor(), además de las acciones que puede realizar un editor añadir_articulo()….

El modelo en SQL para el editor podría ser el siguiente (bueno, en realidad es el script para crear el editor en la base de datos):

create table if not exists editores (
   login varchar(100) not null,
   password varchar(10) not null,
   nombre varchar(200) default ‘’,
   email varchar(100) not null,
   PRIMARY KEY (login)
);

Por ejemplo, si queremos hacer login desde la página index.php tendremos el siguiente código del formulario:

<form method=”post” action=”admin_editor.php?action=login”>
  <table>
   …..

El fichero action_editor.php tendría la siguiente pinta para cada acción que definamos (el código es muy guarrete):

// Si la acción es login
if ($action == “login”) {
   // Comprobamos el nombre de usuario y la contraseña
   $resultado = Array();
   $resultado = comprueba_editor_login();
   // $resultado es un array, donde el primer elemento es “true” o el mensaje de error
   // y el segundo elemento es el ‘login’
   if ($resultado[0] == “true”) {
    session_start();
    $HTTP_SESSION_VARS[’login’] = $resultado[1];
    goto_editor_login_ok();
   }
   else {
    echo $resultado[0];
   }
}

Donde la función goto_editor_login_ok() hace un echo ‘….’ con una página que se redirige a la página con la intranet del editor, ya que el login ha sido correcto.

La idea es definir qué estructura de ficheros hace falta. En lo que tengo hecho tengo tres ficheros por entidad: action_entidad.php, include_entidad.php y db_entidad.php. El primero es el de las acciones, el segundo son funciones auxiliares y el tercero son las funciones más próximas a la base de datos (insertar registro en la BD y demás).

Quizá no haya cogido el mejor ejemplo, porque la función login es muy poco genérica, pero la idea es generar a partir del código SQL de cada entidad las funciones alta, baja y modificación bajo el esquema que te he comentado de usar un fichero intermedio que valide y haga de puente. A partir del fichero SQL y de un fichero de restricciones se podría montar un script que te generase la estructura de páginas en un momento, dejándonos a nosotros la labor de rellenar los huecos con los datos más concretos y poco más.

De todas formas, el sistema es rápido en sí, porque creé una entidad usuario en menos de 10 minutos cambiando editor por usuario y generando los ficheros de include correspondientes.