Skip to content

temple/myprecious.team

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

6 Commits
 
 
 
 

Repository files navigation

SOLUCIÓN A LA PRÁCTICA A1

ENUNCIADO

El enunciado pide cumplir con 6 puntos, tras crear con una carpeta correspondiente a un dominio, en la que habrá que crear una aplicación backend.


PRIMER PUNTO

El primer punto habla de un Front Controller (controlador frontal) y dice de él

..deberá utilizar información del servidor para determinar la ruta solicitada por el usuario en una petición HTTP..

TEORÍA DEL PRIMER PUNTO

Es importante recordar que el controlador frontal es aquél "ente" de la aplicación backend que atiende al servicio web.
El controlador frontal es el archivo de la aplicación backend que el servicio web pide ejecutar al servicio de aplicaciones.
Por lo tanto, el controlador frontal es quien atiende al servicio web cuando este último ha recibido una petición HTTP, a la que hemos venido llamando request.

PLANTEANDO EL PRIMER PUNTO

Si el controlador frontal de las aplicaciones desarrolladas en clase, en un primer inicio usaban un código como

$ruta = $_SERVER['REQUEST_URI'];

y ahora nos encontramos con que usan en su lugar

$ruta = $request->getPathInfo();

podemos asumir sin objeciones que se está obteniendo una información que visiblemente venía del servidor ($_SERVER) y que además guarda relación con la request ($request).

SOLUCIÓN AL PRIMER PUNTO

El primer punto, se resuelve usando cualquiera de los dos códigos vistos en clase que se usaban para obtener el valor que se guardaba en la variable ($ruta), ya que ambos utilizan seguro información que conocía originalmente el servidor web.


SEGUNDO PUNTO

El segundo punto habla del mismo Front Controller y dice de él

..determine el controlador responsable de atender una petición como la anterior..

También se explica que

..mediante un componente de enrutamiento, determine el controlador responsable ..

Y finalmente se dice

..determine (..) la acción a invocar en dicho controlador.

TEORÍA DEL SEGUNDO PUNTO

Sabemos a priori que de controlador frontal únicamente hay uno, porque es el "punto de entrada" a la aplicación backend.

Sabemos también que la misión de los controladores es la de crear una respuesta a las peticiones del usuario (requests).

De los componentes de enrutamiento sabemos bien poca cosa, de momento sabemos que en las aplicaciones backend hay "especialistas" en labores concretas.

En estas labores concretas, sabemos que cada controller se encarga de una página de la aplicación, y también sabemos que las páginas tienen una ruta cada una.

Finalmente sabemos que los controladores tienen una acción llamada indexAction que muestra la página en su estado por defecto, y que las otras acciones muestran la página en otros estados que atienden a la petición del usuario.

PLANTEANDO EL SEGUNDO PUNTO

Si de controlador frontal solo hay uno, entonces forzosamente se está hablando del mismo que en el primer punto.

No nos extraña que se hable de que habrá un controlador responsable de atender una petición como la del primer punto (una request). Es lógico dado que las aplicaciones backend siguen la estructura MVC, y los controladores son los que crean respuestas a las requests que se hayan recibido, usando las vistas.

Sobre el componente, habría que aclarar qué significa "componente" en términos de programación, y concretamente de programación backend.

Finalmente es lógico pensar que la $ruta que aparecía en la solución al primer punto es la guia hacia una página.
Por ende, la ruta es la guia hacia el controlador de esa página.

Todo esto le da un sentido al componente de enrutamiento, que puede ser el especialista en guiar hacia el controlador de la página correspondiente a la ruta.

Adicionalmente, podemos pensar que el componente de enrutamiento también puede ser el especialista en determinar la acción del controlador que mostrará la página en un estado en concreto.

SOLUCIÓN AL SEGUNDO PUNTO

Partiendo de las anteriores conclusiones sabemos ya que existe una variable $request dentro del front controller que representa la petición HTTP dentro de la aplicación.

Por otro lado, carecemos de conocimiento sobre cómo se determinará el controlador delegado pero sabemos que será un controller y también sabemos que quien lo determinará será este "misterioso" componente.

El componente de enrutamiento es un concepto extraño, pero no deja de ser un concepto, por lo tanto, lo podemos representar usando un objeto.

En resumen, partiremos de que conseguiremos un controlador gracias al componente de enrutamiento y a la $ruta.
Y en consecuencia, podemos expresar la conclusión alcanzada usando variables que guarden objetos con funciones, y ejecutando estas funciones a nuestra conveniencia.

La solución quedaría:

$controlador = $componente_enrutamiento->determinarControlador($ruta);
$accion = $componente_enrutamiento->determinarAccion($ruta, $controlador);

TERCER PUNTO

El tercer punto habla nuevamente del Front Controller y dice de él

..responda a la petición (...) por medio de la delegación en otro controlador

Y también se explica que

..responda a la petición (...) ejecutando una acción en este controlador..

TEORÍA DEL TERCER PUNTO

Si cogemos al pié de la letra la teoría del segundo punto, la podemos resumir como:

  1. Solo hay un único front controller
  2. Controladores crean la respuesta a peticiones
  3. El trabajo de responder a una petición se reparte entre especialistas
  4. Cada ruta lleva a una página
  5. Cada página tiene un controlador
  6. La acción index de un controlador muestra la página en su estado por defecto
  7. Las otras acciones de un controlador muestran la página en otros estados

Esta misma teoría nos sirve ahora para plantear este tercer punto.

PLANTEANDO EL TERCER PUNTO

En el segundo punto habíamos creado una variable $controlador que era el controlador responsable (especialista) de atender la petición (crear la respuesta).

Ahora se nos aclara que, aunque el controlador cree la petición, también la enviará (delegado en responder a la petición), por lo tanto habrá que eliminar del controlador frontal cualquier intento de envio de una respuesta.

Finalmente se nos dice que la respuesta a se enviará ejecutando una acción.
Esta acción es con toda probabilidad la que había determinado el componente de enrutamiento, cuando hacíamos $accion = $componente_enrutamiento->determinarAccion($ruta, $controlador);.

Partiendo de esta base sabemos ya que existe una variable $request dentro del front controller, y que esta variable representa la petición HTTP dentro de la aplicación.
Por otro lado, carecemos de conocimiento sobre cómo se determinará el controlador delegado pero sabemos que será un controller y también sabemos que quien lo determinará será este "misterioso" componente.

Por lo tanto almenos partiremos de que conseguiremos un controlador y que este controlador atenderá a la petición (respondiéndola).

SOLUCIÓN AL TERCER PUNTO

La solución al tercer punto deberá ocupar el último lugar dentro del código del controlador frontal, porque el envío de la respuesta es lo último que sucedía, y es lo que justamente vamos a reemplazar.

Por lo tanto podemos expresar la conclusión alcanzada usando variables que tengan objetos con funciones. Y ejecutando estas funciones a nuestra conveniencia.

Nos podría quedar algo como

$controlador->ejecutarAccion($accion,$request);

CUARTO PUNTO

El cuarto punto habla del misterioso Componente de enrutamiento y dice de él

..una clase correspondiente a un componente de enrutamiento..

..dotado de las funciones getController y getAction..

..recibirán como parámetro un string llamado url..

A parte se nos dice de la función getController

..devolverá el FQDN de una clase controller..

Finalmente se nos dice de la función getAction

..devolverá un string..

TEORÍA DEL CUARTO PUNTO

Uno de los conceptos fundamentales de las clases es que: las clases agrupan las propiedades y los métodos de los objetos que podremos crear con ellas ($objeto = new Class();).

Otro concepto teórico importante es que las funciones pueden tener un valor de retorno (return).

Y finalmente sabemos que, en programación, los valores tienen un tipo de datos.

A todo lo anterior necesitaremos aclarar qué tipo de datos es "FQDN". Como se ha dicho es la ruta completa hacia un archivo, y por lo tanto el mejor tipo de datos que pueda corresponderle es un string.

PLANTEANDO EL CUARTO PUNTO

Si las clases sirven para agrupar propiedades y métodos, y nos dicen dos métodos de la clase componente de enrutamiento, habrá que plantear la creación de una clase con estas dos funciones.

Como la primera función (getController) debe devolver un string con el FQDN de un controller, habrá que devolver la ruta entera a un controller; que será un archivo .php guardado dentro de la carpeta src/controller.
Y en tanto que la segunda devolverá un string, este string debería coincidir con una acción de un controller.

Sentado lo anterior, si revisamos la solución del SEGUNDO PUNTO..

$controlador = $componente_enrutamiento->determinarControlador($ruta);
$accion = $componente_enrutamiento->determinarAccion($ruta, $controlador);

..nos damos cuenta de que hay un parámetro que se repite, que es $ruta.

$ruta no deja de ser un trozo de URL (el mas significativo) y podría encajar con este parámetro $url.
Pero ¿qué hacemos entonces con el parámetro $controlador?

Si nos paramos a pensar, si el componente de enrutamiento es capaz de "determinar un controlador a partir de una ruta", debería ser capaz de "determinar una acción a partir únicamente de una ruta", porque el controlador ya lo puede averiguar por sí mismo.

Si replateáramos las dos llamadas a funciones podrían quedar como:

$controlador = $componente_enrutamiento->determinarControlador($ruta);
$accion = $componente_enrutamiento->determinarAccion($ruta);

Como existe una analogía entre ambas funciones (determinarControlador y determinarAccion) con las de este punto, lo que se puede hacer es substituirlas en el front controller.

Finalmente, habrá que hacer que las funciones determinen el controlador y la acción en función del valor de esta $ruta, que será recibida como $url.

SOLUCIÓN AL CUARTO PUNTO

Lo primero que habría que hacer es modificar el front controller y dejar las líneas a reemplazar como:

$controlador = $componente_enrutamiento->getController($ruta);
$accion = $componente_enrutamiento->getAction($ruta);

Además, como sabemos ya que el componente de enrutamiento tendrá una clase, podremos crear un objeto de esa clase y asignarselo a la variable $componente_enrutamiento, inmediatamente antes de usarlo:

$componente_enrutamiento = new ComponenteEnrutamientoClass();

Ahora bastará con definir esta clase en un archivo a parte, y (elegimos src para guardarlo):

class ComponenteEnrutamientoClass{
    // Código con las funciones pendientes
}

y finalmente, dentro de esta clase habrá que crear las dos funciones:

function getController($url){
	if ($url == "/home"){
		$fqdn = __DIR__."/controller/homeController.php";		
	}
	else{
		$fqdn = __DIR__."/controller/errorController.php";
	}
	return $fqdn;
}
function getAction($url){
	return "index";
}

En la primera se usa la $ruta a través del parámetro $url, determinando qué controller usaremos según la ruta.

En la segunda, como presuponemos que ambos controllers tendrán la acción indexAction para mostrar la página "home" y "error", respectivamente, en su estado por defecto.

En definitiva, nos quedará:

class ComponenteEnrutamientoClass{

    function getController($url){
	    if ($url == "/home"){
		    $fqdn = __DIR__."/controller/homeController.php";		
	    }
	    else{
		    $fqdn = __DIR__."/controller/errorController.php";
	    }
	    return $fqdn;
    }


    function getAction($url){
	    return "index";
    }
}

QUINTO PUNTO

El quinto punto habla de dos classes controlador y dice de ambas

..que tengan al menos una función llamada indexAction..

Sobre esta función, nos aclara

..que reciba un único parámetro llamado request..

Y sobre el parámetro nos comenta que

..contendrá la información del servidor relativa a la petición HTTP..

TEORÍA DEL QUINTO PUNTO

Volvamos nuevamente a la teoría del SEGUNDO PUNTO:

  1. Controladores crean la respuesta a peticiones
  2. La acción index de un controlador muestra la página en su estado por defecto

Si a ello le añadimos lo que ya decíamos en el primer punto:

podemos asumir sin objeciones que se está obteniendo una información que visiblemente venía del servidor ($_SERVER) y que además guarda relación con la request ($request).

PLANTEANDO EL QUINTO PUNTO

En este quinto punto repetiremos la misma fórmula que para crear la clase correspondiente al componente de enrutamiento, crearemos una clase por cada controlador.

En cada clase de controlador crearemos una función indexAction.

Llegados a este punto, cabría recordar en qué punto tendríamos el código del controlador frontal.
Deberíamos tener algo como:

// SOLUCIÓN AL PUNTO 1
$ruta = $request->getPathInfo();

// SOLUCIÓN AL PUNTO 4
$componente_enrutamiento = new ComponenteEnrutamientoClass();

// SOLUCIÓN AL PUNTO 2 ACTUALIZADA POR EL PUNTO 4
$controlador = $componente_enrutamiento->getController($ruta);
$accion = $componente_enrutamiento->getAction($ruta);

// SOLUCIÓN AL PUNTO 3
$controlador->ejecutarAccion($accion,$request);

Si nos fijamos bien, habíamos propuesto como solución una función llamada ejecutarAccion.
Esta función ejecutaba la función correspondiente a una acción en el controlador.

El caso es que esta función se la habíamos asignado al $controlador, y por lo tanto tendremos que añadirla a las clases controlador que propongamos en la solución.

La única incógnita que nos queda por solucionar es:
¿Cómo se puede llamar a la función indexAction desde dentro de la función ejecutarAccion?.

La respuesta a esta importante incógnica es la misma que aplicaba en Javascript, la variable this.
En el caso de php, como es una variable se llama $this, y se explica en esta página de php.net.

Esta variable se puede usar desde dentro de cualquier función de un objeto, y la variable guarda al propio objeto, con lo que se puede usar $this como se usaría el propio objeto. Por lo tanto, si el objeto tiene una función llamada indexAction, la variable $this tendrá la misma función.

SOLUCIÓN AL QUINTO PUNTO

Como hemos visto, habrá que crear dos clases, con la función indexAction y la función ejecutarAccion:

class homeController{

    function indexAction($request){
    	// código que muestra la página en su estado por defecto
    }

    function ejecutarAccion($accion, $request){
    	// código que ejecuta la acción que nos digan
    }
}

Ahora nos falta trasladar aquél código que en el PUNTO TERCERO habíamos eliminado, dentro de la función indexAction:

function indexAction($request){
    $response = new BinaryFileResponse(__DIR__.'/view/home.html');
    $response->send();
}

Resta por hacer la función ejecutaAccion, que quedaría como:

function ejecutaAccion($accion,$request){
    if ($accion == 'index'){
        $this->indexAction($request);
    }
}

Y para concluir, el mismo código serviría para el otro controller:

class errorController{

    function indexAction($request){
        $response = new BinaryFileResponse(__DIR__.'/view/error.html');
        $response->send();
    }

    function ejecutarAccion($accion, $request){
        if ($accion == 'index'){
            $this->indexAction($request);
        }
    }
}

About

Sample project for Backend Development learning purposes

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published