Veamos el método "PrepareResponse()" antes de los cambios y comentemos luego qué me ha hecho llevar a cabo dichos cambios.

private function PrepareResponse(){
  global $query, $themes;
  $this->InitializeQuery();
  $this->SendHttpHeaders();
  if($query->IsTrackBack()){
    $trackBack = new TrackBack();
  }elseif($query->IsRssFeed()){
    $rssFeed = new GbRssFeed();
  }elseif($query->IsIndex()){
    $themes->RequireIndexScript();
  }elseif($query->IsPage()){
    $themes->RequirePageScript();
  }elseif($query->IsSingle()){
    $themes->RequireSingleScript();
  }elseif($query->IsArchive()){
    $themes->RequireArchiveScript();
  }elseif($query->Is404Error()){
    $themes->Require404ErrorScript();
  }
  return true;
}

Lo primero que puede verse es el uso de las variables "$trackBack" y "$rssFeed", o, por mejor decir, su "no uso". De de modo que podríamos ahorrárnoslas y retornar directamente los objectos correspondientes. Ahora bien, veamos ahora el método "PrepareResponse()" tal y como ha quedado de momento.

private function PrepareResponse(){
  global $query, $themes;
  $this->InitializeQuery();
  $this->SendHttpHeaders();
  if($query->IsNeedTheme()){
    return $themes->MainRequire();
  }elseif($query->IsRssFeed()){
    return new GbRssFeed();
  }elseif($query->IsTrackBack()){
    return new TrackBack();
  }else{
    // FIXME: Really need this? Why?
    return new GbError(_r(
      'Fatal error: unknown request type'
    ));    	
  }
}

Como puede verse, se han quitado del medio las variables que realmente no se utilizaban, pero, además, observarás cosas nuevas. He pensado (¡oh prodigio!) en que podría usar un método (nuevo) de la clase "Themes" para requerir los distintos "scripts" en función de la petición del usuario.

Pero, no quería dejarlo todo a la clase "Themes", entre otras cosas, porque en los "Trackbacks" y "Feeds" la clase "Themes" no tiene nada que hacer. Así que he añadido un método a la clase "Query", que puede determinar si la petición del usuario necesita temas o no.

Efectivamente, con "IsNeedTheme()" puedo determinar si la clase "Theme" tiene que entrar en acción, y, si es así, dejo ya a esta clase que se encargue de requerir el "script" correspondiente, mediante otro nuevo método "MainRequire()". De hecho tiene lógica, porque, efectivamente, los temas tienen lo que podría llamarse "scripts" "principales" y otros "secundarios".

Pero el método "PrepareResponse()" continuará adelante en caso de que la petición de usuario no requira de tema alguno, puesto que puede tratarse de una petición de "TrackBack" o de la petición de un "Feed RSS". Si esto es así el método "PrepareResponse()" se limita a retornar un objeto de la clase correspondiente. El propio constructor de las clases ponen en marcha el proceso que es menester en su caso.

Y hay una cosa nueva más en esta nueva implementación del método "PrepareResponse()" de la clase "FrontEnd": la posibilidad de llegar a un error "fatal", en caso de que no pueda determinarse si la petición del usuario necesita temas, es un "Trackback" o un "Feed RSS". Nótese el "FIXME", sin embargo, y es que no estoy nada seguro de que nunca vaya a llegarse ahí.

Sin embargo, creo que no está del todo mal tener en cuenta que "algo" puede ir mal, cosa que no podía conocerse en la anterior implementación del método "PrepareResponse()". Por otro lado, tengo mis dudas de que no sea la propia clase "Query" (tal vez su hija "GbQuery") la que debiera dar la oportuna respuesta al usuario.

Pero, con esta última idea, estoy echando por tierra a la clase "FrontEnd", es decir, ¿debería ser esta sustituida por la propia clase "Query" o "GbQuery" implementando esta los métodos oportunos? Ya veremos.

Lo cierto es que ahora creo que no, que debe ser así, que la clase "FrontEnd" tiene su razón de ser y que el trabajo que esta toma (que no está sólo en su método "PrepareResponse()") no debe recaer en otra clase, ni siquiera en la clase "GbQuery", como me pueda parecer.

Actualización: He escrito otra entrada que se relaciona con esta.