En un post anterior les comenté las buenas prácticas en Python, ahora toca hablar de Django, si bien Django esta hecho en el lenguaje Python tiene sus propias convenciones como framework, y seguir estos lineamientos permitirá que tengas proyectos organizados pero sobre todo, que tus compañeros de trabajo (si todos siguen estas recomendaciones) y tu funcionen mejor.

Estilo de código

Aquí no hay mucho que decir, estamos hablando de Python y por lo tanto aplican las reglas de estilo de Código de Python, debes escribir siguiendo la PEP8. Django también tiene sus propias convenciones para escribir código, estas las puedes encontrar aquí , coteja con las de Python, verás que son complementarias.

Settings

settings.py es uno de los módulos principales en tu app, en el se definen los parámetros con los que ha de funcionar tu aplicación, es importante mantener limpio este módulo, e incluso, quitar lo que no es básico para entender el funcionamiento de la aplicación o moverlo a otro lado.

Recordemos que estamos hablando de Python, podemos hacer nuestro settings.py muy modular, e importar lo que se necesita en el momento. Por ejemplo, las configuraciones de logging , o las configuraciones correspondientes al ambiente de desarrollo que son típicamente diferentes a las de producción.

Rutas

Nuestro ambiente de desarrollo esta en una ruta en el almacenamiento diferente de la que estará en producción, es por ello que debemos evitar usar rutas “duras”, en su lugar debemos referirnos a rutas relativas a una que Python nos proporcionará.

Es común ver en el settings.py la variable BASE_DIR y STATIC_ROOT que son variables donde se define la ruta absoluta del proyecto en disco duro, así como donde se guardan los archivos estáticos en disco duro. Estas variables las podemos definir mejor así:

BASE_DIR = os.path.dirname(__file__)
STATIC_ROOT = os.path.join(BASE_DIR, "static")

urls

En nuestro proyecto veremos un archivo urls.py que no es mas que un módulo que contiene la información de cada una e las URLs dentro de nuestro proyecto. Me ha tocado ver urls.py tan largos como la cuaresma, y no, no es nada bonito tener un módulo asi de grande, sobre todo porque es confuso.

Que podemos hacer entonces?. Bueno, en principio, tener un urls.py en cada app de tu proyecto, de esta forma cada app será independiente, se reducirá el tamaño del archivo principal y te será m as fácil ubicar las urls en caso de agregar/editar/borrar. La otra, en el caso de que nuestra app tenga muchas urls, es modularizar, puedes repartir las urls en mas módulos dependiendo de cada sección dentro de tu app.

Plantillas

Las plantillas en Django están en básicamente en dos lugares, en el directorio base de tu proyecto y en el de cada app, ahí deberá haber un directorio llamado templates. Lo importante aquí es que las plantillas de tu app deben estar en el directorio templates dentro de tu app. Las plantillas “base” o genéricas podrían estar en tu directorio templates en el directorio base.

BASE_DIR/
        /myproject/
                  /settings.py
                  /urls.py
        /templates/
                  /base.html
                  /header.html
                  /footer.html
        /my_app/
               /models.py
               /views.py
               /urls.py
               /admin.py

Contenido estatico

Lo mismo que con las plantillas. Cada app debe mantener su contenido estático para cada una de ellas, con esto mantienes la independencia de la app y permites que pueda ser usada en otros proyectos.

El contenido estático pueden ser:

• imágenes
• JavaScript
• CSS

Ojo, no se debe confundir el contenido estático con el contenido que sube el usuario final, este contenido que sube el usuario va al directorio “Media”

Otras convenciones que aplico yo

Estas no están dentro de las convenciones de las buenas prácticas en Django, pero las he usado y me han servido muy bien:

Convertir views.py /forms.py en un paquete

Con esto puedo seccionar las partes de mi app, así tengo Views para cada sección y son generalmente archivos pequeños. Con esto evito tener un “views” de mas de 1000 lineas.

BASE_DIR/
        /myproject/
        /my_app/
               /models.py
               /urls.py
               /admin.py
               /views/
                     /customers.py
                     /products.py
                     /reports.py

Usar siempre Class Views

Django desde hace buen tiempo ya cuenta con las Class Views. Antes estábamos acostumbrados a que cada vista era una función, pero los Class Views tienen muchas ventajas sobre las funciones.

Lo que mas me gusta es que puedo crear una clase base y solo extender su uso dependiendo de la sección, por ejemplo, tengo la sección Customers, entonces creo una vista básica de “customers”:

class CustomerBasicView(LoginRequiredMixin ,TemplateView):
    template_name = "blank.html"
    # Esta variable de clase se llenará con el valor delcliente en turno.
    customer = None

    def get_context_data(self, *args, **kwargs):
        # Crear el contexto y llenar lo "General"

    def get(self, request, *args, **kwargs):
        # Llamar get_context_data
        # Llamar una función en las clases hijas para complementar el contexto
        # Ejecutar una función anexa a "get" para finalizar get
        # Si no existe dicha función retrnar
        return self.render_to_response(self.context)

Y las demás clases solo necesitan heredar de CustomerBasicView

class Dashboard(CustomerBasicView):
    template_name="customers/dashboard.html"

class View(CustomerBasicVIew):
    template_name="customers/view.html"

class Edit(CusotmerBasicView):
    template_name="customers/edit.html"

Como ven?. Dejaré una explicación mas detallada de esto que hago para otro post. Tal vez mañana.

Si te gustó el articulo, compartelo en tus redes sociales, si tienes algo que agregar con toda confianza hazlo en los comentarios.