{"id":5449,"date":"2018-07-27T13:51:21","date_gmt":"2018-07-27T18:51:21","guid":{"rendered":"https:\/\/islascruz.org\/blog\/?p=5449"},"modified":"2018-08-02T23:47:30","modified_gmt":"2018-08-03T04:47:30","slug":"buenas-practicas-en-django","status":"publish","type":"post","link":"https:\/\/islascruz.org\/blog\/2018\/07\/27\/buenas-practicas-en-django\/","title":{"rendered":"Buenas practicas en Django"},"content":{"rendered":"

En un post anterior les coment\u00e9 las buenas pr\u00e1cticas 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\u00e1 que tengas proyectos organizados pero sobre todo, que tus compa\u00f1eros de trabajo (si todos siguen estas recomendaciones) y tu funcionen mejor.<\/p>\n

Estilo de c\u00f3digo<\/h3>\n

Aqu\u00ed\u00a0no hay mucho que decir, estamos hablando de Python y por lo tanto aplican las reglas de estilo de C\u00f3digo de Python, debes escribir siguiendo la PEP8. Django tambi\u00e9n tiene sus propias convenciones para escribir c\u00f3digo, estas las puedes encontrar aqu\u00ed<\/a> , coteja con las de Python, ver\u00e1s que son complementarias.<\/p>\n

Settings<\/h3>\n

settings.py es uno de los m\u00f3dulos principales en tu app, en el se definen los par\u00e1metros con los que ha de funcionar tu aplicaci\u00f3n, es importante mantener limpio este m\u00f3dulo, e incluso, quitar lo que no es b\u00e1sico para entender el funcionamiento de la aplicaci\u00f3n o moverlo a otro lado.<\/p>\n

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<\/code>\u00a0, o las configuraciones correspondientes al ambiente de desarrollo que son t\u00edpicamente diferentes a las de producci\u00f3n.<\/p>\n

Rutas<\/p>\n

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

Es com\u00fan ver en el settings.py la variable BASE_DIR<\/code>\u00a0y STATIC_ROOT<\/code>\u00a0que son variables donde se define la ruta absoluta del proyecto en disco duro, as\u00ed como donde se guardan los archivos est\u00e1ticos en disco duro. Estas variables las podemos definir mejor as\u00ed:<\/p>\n

BASE_DIR = os.path.dirname(__file__)\nSTATIC_ROOT = os.path.join(BASE_DIR, \"static\")<\/pre>\n
urls<\/h3>\n
En nuestro proyecto veremos un archivo urls.py<\/code>\u00a0que no es mas que un m\u00f3dulo que contiene la informaci\u00f3n 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\u00f3dulo asi de grande, sobre todo porque es confuso.<\/p>\n
Que podemos hacer entonces?. Bueno, en principio, tener un urls.py en cada app<\/code>\u00a0de tu proyecto, de esta forma cada app ser\u00e1 independiente, se reducir\u00e1 el tama\u00f1o del archivo principal y te ser\u00e1 m as f\u00e1cil 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\u00f3dulos dependiendo de cada secci\u00f3n dentro de tu app.<\/p>\n
Plantillas<\/h3>\n
Las plantillas en Django est\u00e1n en b\u00e1sicamente en dos lugares, en el directorio base de tu proyecto y en el de cada app, ah\u00ed deber\u00e1 haber un directorio llamado templates.<\/em>\u00a0Lo importante aqu\u00ed es que las plantillas de tu app deben estar en el directorio templates dentro de tu app. Las plantillas “base” o gen\u00e9ricas podr\u00edan estar en tu directorio templates en el directorio base.<\/p>\n
BASE_DIR\/\n        \/myproject\/\n                  \/settings.py\n                  \/urls.py\n        \/templates\/\n                  \/base.html\n                  \/header.html\n                  \/footer.html\n        \/my_app\/\n               \/models.py\n               \/views.py\n               \/urls.py\n               \/admin.py\n<\/pre>\n
Contenido estatico<\/h3>\n
Lo mismo que con las plantillas. Cada app debe mantener su contenido est\u00e1tico para cada una de ellas, con esto mantienes la independencia de la app y permites que pueda ser usada en otros proyectos.<\/p>\n
El contenido est\u00e1tico pueden ser:<\/p>\n
    \n
  • im\u00e1genes<\/li>\n
  • JavaScript<\/li>\n
  • CSS<\/li>\n<\/ul>\n
    Ojo, no se debe confundir el contenido est\u00e1tico con el contenido que sube el usuario final, este contenido que sube el usuario va al directorio “Media”<\/p>\n
    Otras convenciones que aplico yo<\/h3>\n
    Estas no est\u00e1n dentro de las convenciones de las buenas pr\u00e1cticas en Django, pero las he usado y me han servido muy bien:<\/p>\n
    Convertir views.py \/forms.py en un paquete<\/h4>\n
    Con esto puedo seccionar las partes de mi app, as\u00ed tengo Views para cada secci\u00f3n y son generalmente archivos peque\u00f1os. Con esto evito tener un “views” de mas de 1000 lineas.<\/p>\n
    BASE_DIR\/\n        \/myproject\/\n        \/my_app\/\n               \/models.py\n               \/urls.py\n               \/admin.py\n               \/views\/\n                     \/customers.py\n                     \/products.py\n                     \/reports.py\n\n<\/pre>\n
    Usar siempre Class Views<\/h4>\n
    Django desde hace buen tiempo ya cuenta con las Class Views. Antes est\u00e1bamos acostumbrados a que cada vista era una funci\u00f3n, pero los Class Views tienen muchas ventajas sobre las funciones.<\/p>\n
    Lo que mas me gusta es que puedo crear una clase base y solo extender su uso dependiendo de la secci\u00f3n, por ejemplo, tengo la secci\u00f3n Customers, entonces creo una vista b\u00e1sica de “customers”:<\/p>\n
    class CustomerBasicView(LoginRequiredMixin ,TemplateView):\n    template_name = \"blank.html\"\n    # Esta variable de clase se llenar\u00e1 con el valor delcliente en turno.\n    customer = None\n\n    def get_context_data(self, *args, **kwargs):\n        # Crear el contexto y llenar lo \"General\"\n\n    def get(self, request, *args, **kwargs):\n        # Llamar get_context_data\n        # Llamar una funci\u00f3n en las clases hijas para complementar el contexto\n        # Ejecutar una funci\u00f3n anexa a \"get\" para finalizar get\n        # Si no existe dicha funci\u00f3n retrnar\n        return self.render_to_response(self.context)<\/pre>\n
    Y las dem\u00e1s clases solo necesitan heredar de CustomerBasicView<\/code><\/p>\n
    class Dashboard(CustomerBasicView):\n    template_name=\"customers\/dashboard.html\"\n\nclass View(CustomerBasicVIew):\n    template_name=\"customers\/view.html\"\n\nclass Edit(CusotmerBasicView):\n    template_name=\"customers\/edit.html\"<\/pre>\n
    Como ven?. Dejar\u00e9 una explicaci\u00f3n mas detallada de esto que hago para otro post. Tal vez ma\u00f1ana.<\/p>\n
    \n
    Si te gust\u00f3 el articulo, compartelo en tus redes sociales, si tienes algo que agregar con toda confianza hazlo en los comentarios.<\/p>\n
    <\/div>\n
    <\/path><\/svg><\/i> \"Loading\"<\/p>\n
    <\/div>\n","protected":false},"excerpt":{"rendered":"
    Aqu\u00ed\u00a0no hay mucho que decir, estamos hablando de Python y por lo tanto aplican las reglas de estilo de C\u00f3digo de Python, debes escribir siguiendo la PEP8. Django tambi\u00e9n tiene sus propias convenciones para escribir c\u00f3digo, estas las puedes encontrar aqu\u00ed , coteja con las de Python, ver\u00e1s que son complementarias.<\/p>\n
    <\/div>\n
    <\/path><\/svg><\/i> \"Loading\"<\/p>\n
    <\/div>\n","protected":false},"author":1,"featured_media":5439,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[14,15,239],"tags":[565,994,16,34,995,993],"class_list":["post-5449","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-programming","category-python","category-tips-and-tricks","tag-django","tag-modelos","tag-python-2","tag-tips","tag-trucos","tag-views"],"a3_pvc":{"activated":true,"total_views":14929,"today_views":0},"brizy_media":[],"_links":{"self":[{"href":"https:\/\/islascruz.org\/blog\/wp-json\/wp\/v2\/posts\/5449","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/islascruz.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/islascruz.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/islascruz.org\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/islascruz.org\/blog\/wp-json\/wp\/v2\/comments?post=5449"}],"version-history":[{"count":8,"href":"https:\/\/islascruz.org\/blog\/wp-json\/wp\/v2\/posts\/5449\/revisions"}],"predecessor-version":[{"id":5475,"href":"https:\/\/islascruz.org\/blog\/wp-json\/wp\/v2\/posts\/5449\/revisions\/5475"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/islascruz.org\/blog\/wp-json\/wp\/v2\/media\/5439"}],"wp:attachment":[{"href":"https:\/\/islascruz.org\/blog\/wp-json\/wp\/v2\/media?parent=5449"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/islascruz.org\/blog\/wp-json\/wp\/v2\/categories?post=5449"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/islascruz.org\/blog\/wp-json\/wp\/v2\/tags?post=5449"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}