Pyramid: 2 - Entendiendo la estructura del proyecto

En la anterior entrada hemos visto lo más básico de cómo crear un entorno y un proyecto inicial con Pyramid + ZODB, en este post vamos a intentar entender el proyecto y adaptarlo un poco a nuestra forma de trabajar, para ello nada mejor que empezar echándole un vistazo a lo que pcreate ha hecho por nosotros:

$ cd src/
$ ls
CHANGES.txt     Data.fs.lock    README.txt      setup.cfg       src.egg-info/
Data.fs         Data.fs.tmp     development.ini setup.py
Data.fs.index   MANIFEST.in     production.ini  src/

En este primer nivel, además de los correspondientes ficheros de texto README y CHANGES, debemos destacar varios elementos:

• Archivos .ini (developent.ini, production.ini...): Son los archivos de configuración de entorno. Pyramid sabe que habrá configuraciones distintas dependiendo del entorno así que nos ofrece la posibilidad de utilizar archivos distintos para jugar a nuestro antojo.
• Data.*: Son los archivos que utiliza ZODB como base de datos, donde se guardará toda la información persistente.
• setup.py, MANIFEST.in: Archivos de Python necesarios por si queremos empaquetar nuestra aplicación como bundle.
• src/: Directorio donde realmente irá la lógica de la aplicación, modelos, vistas y templates (MVT).

Bajando otro nivel (src/ nuevamente) nos encontramos con un proyecto en blanco listo para empezar a picar código. Decir que Pyramid (como Django y otros frameworks), siguen el patrón MVT (model-view-template), donde el modelo se encarga de enlazar con los datos persistentes, la vista es la lógica de la aplicación (controlador) y los templates son las plantillas que moldean la aplicación en lenguaje de marcado.

$ cd src/
$ ls
__init__.py   models.py    static/       tests.py     views.py
templates/

Creo que no hay mucho que explicar, la nomenclatura es más que explícita. Por defecto Pyramid nos ofrece llevar toda la lógica de la aplicación en un fichero (views.py) y el/los modelo(s) en otro (models.py); sin embargo como es muy listo y sabe que la aplicación tendrá más de una plantilla nos ofrece el directorio templates/ para que vayamos guardando ahí dentro nuestras obras de arte, lo mismo que con los archivos estáticos (static/).

¿Qué pasaría si queremos, por organización o limpieza, separar los modelos o la lógica de la aplicación en ficheros distintos?. El siguiente paso será modificar mínimamente la forma de trabajar con Pyramid para que lea los modelos de un directorio models/ y la lógica del directorio views/.

La sencillez de Python nos permite crear un módulo importable en cualquier directorio que exista un __init__.py vacío, de forma que si creamos el directorio models/ y dentro ubicamos este mágico recurso, ya podríamos importar nuestros modelos llamándolos con un "import models.my_model". Ya hemos hecho la mitad del trabajo hecho.

Para la otra mitad debemos convertir nuestro views.py en el __init__.py del directorio views/ de forma que cargue ese archivo por defecto antes de leer ninguna otra vista. Podemos reescribirlo de la siguiente forma:

from pyramid.view import view_config
from .models import my_model
BASE_TMPL = 'src:templates/'

@view_config(context=my_model, renderer=BASE_TMPL + 'index.pt')
def my_view(request):
    return {'project': 'src'}

Importamos un my_model.py dentro de models/ y aprovechamos para configurar templates/ como el directorio por defecto de las plantillas. Ahora está todo un poco más ordenado y sin apenas esfuerzo.

El siguiente paso es intentar entender el URL Dispatcher de Pyramid y, si nos vemos con fuerza y ganas, el Traversal de la ZODB y sus recursos Root y Folder.