Bitácora de Gesbit

Uno de los beneficios de requerir PHP 5 en Gesbit es que se hace uso de la función "mágica" "autoload()", que, como sabes, permite a PHP "requerir" las clases necesarias según estas se necesitan, sin necesidad de requerirlas una a una por nuestra cuenta y riesgo, como se hace en PHP 4.

Además dicha función da más juego, porque, al dejarnos requerir en el cuerpo de la función un "script" (el de la clase que se precisa) podemos hacer otras cosas además. En Gesbit, por ejemplo, la clase "Input" definida en "input.class.php", se apoya en otro "script" "input.const.php", que es requerido en la propia función "autoload()".

Sin embargo me planteo cambios en Gesbit para evitar algo que empieza a preocuparme. Las clases de Gesbit se guardan todas en "/gb-auxiliar/classes/", las que pertenecen a Gesbit, por decirlo así, porque las clases de terceros, se guardan en subdirectorios del directorio "classes".

Esto hace que la función "autoload()" de Gesbit quede tal que así en el archivo "/gb-auxiliar/requires/gb-autoload.php":

function __autoload($className){
  $className = strtolower($className);
  $classFile = $className.GB_AUTOLOAD_CLASS_EXT;
  $constFile = $className.GB_AUTOLOAD_CONST_EXT;
  // Test if the class is a Gesbit main class
  if(file_exists(GB_CLASSES_DIR.$classFile)){    
    require(GB_CLASSES_DIR.$classFile);
    // Find a possible "class constants" file
    if(file_exists(GB_CLASSES_DIR.$constFile)){
      require(GB_CLASSES_DIR.$constFile);
    }
  // Maybe is a KSes class
  }elseif(file_exists(GB_KSES_DIR.$classFile)){
    require(GB_KSES_DIR.$classFile);
  // Maybe a PHPASS class
  }elseif(file_exists(GB_PHPASS_DIR.$classFile)){
    require(GB_PHPASS_DIR.$classFile);
  // Maybe a Snoopy class
  }elseif(file_exists(GB_SNOOPY_DIR.$classFile)){
    require(GB_SNOOPY_DIR.$classFile);        
  // Maybe a PHP Gettext class
  }elseif(file_exists(GB_PHPGETTEXT_DIR.$classFile)){
    require(GB_PHPGETTEXT_DIR.$classFile);
  }
}

Como ves se comprueba la existencia de la clase requerida en el directorio de clases de Gesbit. Si existe ahí la clase requerida, se busca su "script" de "constantes", y, si existe se requiere también. En otros casos se busca la clase requerida dentro de los subdirectorios de las clases de terceros.

Ahora bien, si se añaden más clases de terceros, más subdirectorios en el directorio de clases, el cuerpo de la función "autoload" tendrá que crecer, mientras que, y este es el cambio que estoy considerando, si todas las clases se guardan en el directorio de clases, la función "autoload" podría quedar así "para siempre":

function __autoload($className){
  $className = strtolower($className);
  $classFile = $className.GB_AUTOLOAD_CLASS_EXT;
  $constFile = $className.GB_AUTOLOAD_CONST_EXT;
  // Test if the class is a Gesbit main class
  if(file_exists(GB_CLASSES_DIR.$classFile)){    
    require(GB_CLASSES_DIR.$classFile);
    // Find a possible "class constants" file
    if(file_exists(GB_CLASSES_DIR.$constFile)){
      require(GB_CLASSES_DIR.$constFile);
    }
  }
}

Ahora bien, si así parece mejor, ¿dónde está mi duda entonces? Pues que en mantener las clases de terceros separadas del resto no parece una mala idea. Hay clases de terceros que son en realidad una sola clase, pero, hay otras, que cuentan con varias. Creo que mezclar todas las clases en un solo directorio no es tan "limpio" como si se separan en subdirectorios.

Y, sin embargo, ahí está el problema: si se ve bien dejar el asunto como está, la función "autoload" crecerá irremediablemente, según se añadan clases de terceros en Gesbit. Y también será preciso definir nuevas constantes. En definitiva, un trabajo extra y que al cabo puede llegar a contar con una función "autoload" de dos mil líneas.

Pues en esas estamos. Lo mismo ocurre con los "script" JavaScript. Estos se guardan en el directorio "/gb-auxiliar/jscripts/", y los "scripts" de terceros se guardan en subdirectorios de este directorio. Si bien aquí no hay función "autoload" de por medio: cuando se precisa un "script" se requiere allí donde está, sin más, no se da el "problema" descrito arriba.

En fin, ya veremos en qué queda esto. Si se te ocurre alguna idea y quieres hacérmela saber, que sepas que te la agradezco de antemano, que será bienvenida, en todo caso. Lo que más me retiene de hacer los cambios necesarios es que puede haber clases de terceros que sean más bien completas "librerías", y que estas estén en sus propios directorio no me parece mal.

Mira, por ahí pueden ir los tiros: discriminar las clases que verdaderamente se merezcan un subdirectorio (porque usen otros "scripts" propios, por ejemplo) y no solamente en función de si son de terceros o no lo son.