From 2bcfa6effb143fca343ca0d384f3a298d9158665 Mon Sep 17 00:00:00 2001
From: Guillermo Ramos
Date: Thu, 26 Jun 2014 02:09:35 +0200
Subject: Implementación del servidor web

---
 memoria.tex | 137 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 128 insertions(+), 9 deletions(-)

(limited to 'memoria.tex')

diff --git a/memoria.tex b/memoria.tex
index f14d7db..57538c3 100755
--- a/memoria.tex
+++ b/memoria.tex
@@ -289,7 +289,7 @@ verá en el apartado \ref{sec:tactics}.
 Para poder razonar sobre distribuciones de probabilidad, EasyCrypt proporciona
 un tipo (\rawec{'a distr}) que representa sub-distribuciones discretas sobre
 \rawec{'a}. La principal herramienta para trabajar sobre sub-distribuciones es
-el operador (\rawec{op mu : 'a distr -> ('a -> bool) -> real}), que devuelve la
+el operador \\ (\rawec{op mu : 'a distr -> ('a -> bool) -> real}), que devuelve la
 probabilidad de un evento. Por ejemplo, la distribución uniforme sobre booleanos
 está definida en la biblioteca estándar de EasyCrypt de la siguiente manera
 (\rawec{charfun} es la función característica de p evaluado en x, es decir,
@@ -764,14 +764,14 @@ encuentre los identificadores `cost` y `caxiom`, respectivamente:
 \begin{code}
   \begin{minted}{ocaml}
 let _keywords = [
-"admit" , ADMIT;
-"forall", FORALL;
-"exists", EXIST;
-"pragma", PRAGMA;
-(* ... *)
-
-"cost"  , COST;
-"caxiom", CAXIOM
+  "admit" , ADMIT;
+  "forall", FORALL;
+  "exists", EXIST;
+  "pragma", PRAGMA;
+  (* ... *)
+
+  "cost"  , COST;
+  "caxiom", CAXIOM
 ]
 
 let keywords = Hastbl.create 100
@@ -1016,28 +1016,147 @@ class File(models.Model):
     project = models.ForeignKey(Project)
     # ...
   \end{minted}
+  \caption{models.py}
 \end{code}
 
+Una vez definidos los modelos, Django genera automáticamente la base de datos
+(modelo $\rightarrow$ tabla, atributo $\rightarrow$ columna, ...)  y la reifica
+(representando cada entrada en la base de datos como un objeto en Python), para
+poder hacer un uso totalmente transparente de ella. Además, Django incluye
+varios controladores de gestores de bases de datos que abstraen su acceso y
+hacen posible intercambiarlos sin mayor problema. En nuestro caso, debido a la
+facilidad de uso y la poca carga que tendrá el sistema, usaremos el gestor de
+bases de datos \textbf{SQLite}\footnote{\url{http://www.sqlite.org/}}, aunque
+debería ser trivial cambiarlo en el futuro por cualquier otro gestor.
+
 \subsection{Vista}
+\label{sec:vista}
+
+La vista es el subsistema encargado de generar y servir la parte visual de la
+web: ficheros HTML (posiblemente incluyendo también código JavaScript y/o CSS).
+
+En Django, la vista la implementa un sistema de plantillas (<<templates>>). Una
+plantilla no es más que un fichero HTML incompleto que Django rellena en tiempo
+de ejecución sustituyendo ciertas meta-directivas por código HTML válido. Las
+plantillas se almacenan normalmente en un directorio ``/templates'', separadas
+del resto del código del proyecto.
+
+Para desarrollar la interfaz web ha sido necesario escribir un total de 4
+plantillas, descritas a continuación junto con una captura de pantalla de su
+resultado una vez servidas:
+
+\begin{itemize}
+\item \textbf{base.html}, donde se define la estructura HTML básica del sitio
+  web y se cargan recursos externos como el tema CSS, bibliotecas de JavaScript,
+  etc. No se usa directamente, sino que se importa desde otras plantillas usando
+  la directiva \textbf{extends} de Django.
+\item \textbf{login.html}, servida cuando se accede a la página de inicio de
+  sesión. Un ejemplo de su resultado final:
+
+  TODO captura de pantalla
+\item \textbf{register.html}, servida cuando se accede a la página de registro
+  de usuarios. Su resultado:
+
+  TODO captura de pantalla
+\item \textbf{index.html}, la plantilla que sirve la pantalla principal. Cuando
+  no hay ninguna sesión iniciada, se muestra un mensaje de bienvenida:
+
+  TODO captura de pantalla
+
+  Una vez el usuario ha iniciado sesión, se muestra la página principal de la
+  interfaz web, con navegador de proyectos, editor de texto y resultados de la
+  evaluación.
+\end{itemize}
 
 \subsection{Controlador}
+\label{sec:controlador}
+
+Por último, el controlador es la parte que coordina las otras dos (modelo y
+vista) e implementa la lógica del sitio web como tal. En Django esto se lleva a
+cabo fundamentalmente en dos ficheros:
+
+\begin{itemize}
+\item \textbf{views.py}. En este fichero se definen las \textbf{vistas}, que es,
+  curiosamente, el término que usa Django para denominar a las funciones que
+  reciben una petición y devuelven una respuesta HTTP conteniendo, normalmente,
+  una plantilla ya procesada. Este es el mecanismo básico que controla el
+  comportamiento del sitio web: al acceder a una URI concreta se ejecuta una
+  vista que decide, en función de los datos contenidos en la petición (sesión,
+  usuario autenticado, método HTTP, etc.) qué plantilla servir y cómo
+  rellenarla.
+
+  Para implementar la funcionalidad del sitio web se han tenido que implementar
+  varias vistas, tratando dentro de lo posible que cada vista esté asociada a un
+  recurso, y haga una cosa u otra en función del método HTTP (arquitectura
+  REST). Debido a que la mayor parte de la funcionalidad del sistema se
+  encuentra en la interfaz del usuario (cliente pesado), la interacción con el
+  servidor se reduce prácticamente al intercambio de datos: proyectos y
+  ficheros.
+\item \textbf{urls.py}. En este fichero se configura qué vista ha de invocarse
+  cuando el usuario accede a una determinada URI. El formato es bastante
+  sencillo: las URI se especifican usando expresiones regulares, y cuando la
+  solicitud coincide con una de ellas, se invoca la vista correspondiente
+  pasándole como argumentos la solicitud en cuestión y, opcionalmente,
+  argumentos especificados en la expresión regular.
+
+  Pongamos un ejemplo real de nuestra implementación. Esta línea en urls.py se
+  encarga de gestionar las solicitudes relacionadas con un fichero en concreto
+  (obtener su contenido, actualizarlo, eliminarlo, etc.):
+
+  \begin{code}
+    \begin{minted}{python}
+url(r'^files/(?P<file_id>\d+)', views.file_mgr)
+    \end{minted}
+    \caption{urls.py}
+  \end{code}
+
+  El primer campo es la expresión regular. Los paréntesis a continuación de la
+  barra <</>> indican un campo cuyo valor es de uno o más dígitos y que se le
+  debe pasar a la vista como argumento de nombre <<file_id>>.  En este caso, un
+  acceso a ``/files/13/'' devolvería el resultado de ejecutar la vista de la
+  siguiente forma:
+
+  \begin{code}
+    \begin{minted}{python}
+views.file_mrg(request, file_id=13)
+    \end{minted}
+  \end{code}
+
+  (Que devuelve el contenido del fichero cuyo atributo ``id'' es 13).
+
+  Dentro de las URI que se han diseñado para interactuar con nuestro sistema,
+  algunas están pensadas para que el usuario pueda acceder directamente o forman
+  parte de la navegación normal (``/login'', ``/logout'', etc) y cuya respuesta
+  es siempre HTML, mientras que otras se usan como interfaz directa a los datos
+  (``/files'', ``/projects'', etc) y devuelven información en formato JSON. De
+  estas segundas hablaremos con más detalle en la sección siguiente (TODO
+  seguro?)  (\ref{sec:impl-cliente}).
+
+\end{itemize}
 
 \section{Implementación: cliente}
+\label{sec:impl-cliente}
 
 TODO
 
 \section{Implementación: servidor EasyCrypt}
+\label{sec:impl-serv-easycrypt}
 
 TODO
 
+% A dormir!
+
 \emptypage
 \chapter{RESULTADOS Y CONCLUSIONES}
+\label{cha:result-y-concl}
 
 \emptypage
 \chapter{CONTRIBUCIONES}
+\label{cha:contribuciones}
 
 \emptypage
 \chapter{ANEXOS}
+\label{cha:anexos}
 
 \pagebreak \bibliography{bib}{} \bibliographystyle{ieeetr}
 
-- 
cgit v1.2.3

