Entradas sobre "convenciones":

Convenciones de aplicaciones reusables en Django

Este post es una traducción al español de Django reusable apps conventions, escrito por Eric Holscher. Trata de servir como punto de referencia sobre las mejores prácticas y convenciones en Django. También te pueden interesar las convenciones de proyecto en Django.

¿Qué es una aplicación reusable?

Una aplicación Django reusable es una aplicación que se puede añadir fácilmente a un proyecto y que ofrece una funcionalidad muy específica. Las aplicaciones reusables deberían centrarse en seguir la filosofía Unix de "haz una cosa y hazla bien". Hay más información sobre esto en la charla sobre aplicaciones reusables que dio James Bennett en la Djangocon.

¿Cómo puedo distribuir mi aplicación?

Django debería estar usando el Indice de Paquetes Python (también conocido como Pypi ó Cheese Shop). Hay un tutorial que explica cómo empaquetar y subir tu aplicación a Pypi. Todas las aplicaciones reusables deberían ser subidas a Pypi.

Si subes tu aplicación a Pypi generalmente es una buena idea utilizar el prefijo "django-" en el nombre del proyecto.

Ten también en cuenta que más abajo cuando nos referimos al lugar por omisión para algo como un archivo, esto significa que puedes hacer un directorio con ese mismo nombre como se hace normalmente en Python.

Modelos

Situados en APP/models.py (.py ó un directorio)
Siguiendo el modelo de convenciones de Django

URLs

Situadas en APP/urls.py (.py ó un directorio)
Deben tener un atributo name para que sean reversibles; por ejemplo un nombre siguiendo la nomenclatura APLICACION_MODELO_VISTA, por ejemplo blog_post_detail ó blog_post_list.

Vistas

Situadas en APP/views.py (.py ó un directorio)
Pueden ser cualquier función Python
Las vistas deben proveer valores por defecto fácilmente reemplazables. Por ejemplo:

def register(request, success_url=None,
    form_class=RegistrationForm
    template_name='registration/registration_form.html',
    extra_context=None):

Admin

No requerido
Situado en APP/admin.py
Clases Admin para un MODELO deben ser llamadas MODELOAdmin

Plantillas

Situadas en APP/templates/APP/template.html

En un esfuerzo por estandarizar el nombre de bloques en las plantillas de Django se proponen los siguientes bloques para uso común.

{% block title %}

Éste será el bloque en el que definas el título de la página. Preferiblemente tu base.html definirá el nombre de tu sitio web (a lo mejor incluso utilizando el Sites framework) fuera de esta etiqueta para que aparezca en todas las páginas.
{% block extra_head %}

Éste es uno que mucha gente ya está utilizando de una u otra forma. En tu plantilla base tienes cosas en <head> que son utilizadas para todas las demás. Sin embargo, muchas otras páginas necesitan incluir cosas distintas dentro de <head>, como feeds RSS, Javascript, CSS y otras cosas que deben ir en la cabecera. Probablemente necesitarás otros bloques especializados (como el title descrito anteriormente) que se encuentren en otras partes de <head>.
{% block body %}

Esta etiqueta se pondrá englobando toda la sección <body> de la página. Esto te permite crear páginas en tu aplicación que reemplacen la página entera, no sólo el contenido. No la usarás mucho, pero es una etiqueta realmente útil cuando la necesitas. Se intenta mantener el nombre de las etiquetas de forma coherente con las etiquetas HTML cuando es posible.
{% block menu %}

En este bloque deberá estar tu menú. Es donde se debe incluir la navegación general del sitio web, no una sub-navegación interna de una página.
{% block content %}

Este es el lugar para definir el contenido de una página. Preferiblemente será lo que cambie en cada página. No incluirá ninguna navegación del sitio, cabeceras, pies de página, o nada que debiera pertenecer a una plantilla base.

Otros bloques posibles

{% block content_title %}

Este bloque estará donde se encuentre el "título" de un bloque de contenido. También puede incluir algún tipo de navegación entre contenidos u otras cosas similares. Preferiblemente algo que no esté en el contenido de las páginas principales. (Sin embargo a lo mejor debería ir dentro de la etiqueta content y usar otra etiqueta main_content en vez de la etiqueta content propuesta anteriormente.)
{% block header %} {% block footer %}

Para cualquier area de texto en la cabecera ó pie que pueda cambiar según la página.
{% block body_id %} {% block body_class %}

Este bloque se usará para especificar los atributos class ó id de la etiqueta <body> del documento. Es útil especificarlo para el uso de estilos CSS y otras propiedades.
{% block [section]_menu %} {% block page_menu %}

Este bloque sería el opuesto al bloque menu propuesto anteriormente. Debería ser un menú para una sección o página.

Documentación

Situada en un directorio docs en el mismo nivel que el directorio APP (claro está que para esto debes tener un directorio por encima de tu aplicación)
Puede contener plantillas de referencia

Forms

Situados en APP/forms.py

Template tags

Situados en APP/templatetags/APP_tags.py

Sintaxis propuesta para template tags

as (variable de contexto): Usado para poner una variable en el contexto de una página.
for (objeto o app.modelo): Usado para designar un objeto para una acción que debe ejecutar.
limit (número): Usado para limitar el resultado a un número concreto de resultados.
exclude (objeto o pk): Igual que for pero usado para excluir cosas de ese tipo.

Tests

Situados en APP/tests.py (.py ó un directorio)
Las fixtures se sitúan en APP/fixtures/fixture.json
Generalmente sobreescriben la clase Testcase de Django.

Middleware

Situados en APP/middleware.py
Los mínimos posibles

Context Processors

Situados en APP/context_processors.py

Managers

Situados en APP/managers.py

Feeds

Situados en APP/feeds.py

Publicado por Antonio Melé el Viernes 1 d Mayo d 2009 | 1 comentario | Categorías: aplicaciones, convenciones

Convenciones de proyecto en Django

Django ofrece una flexibilidad muy grande a la hora de configurar nuestros proyectos permitiéndonos organizarlos con estructuras muy diversas. Esta flexibilidad permite que podamos adaptar Django a necesidades concretas pero por otro lado hace que mucha gente se pregunte cuál es la manera correcta de organizar la estructura de sus proyectos. Convenciones en Django, creado por Eric Holscher, pretende ser un punto de referencia sobre las mejores prácticas y convenciones en Django. Esto es una traducción al español de las convenciones sobre proyectos.

Qué es un proyecto

Un proyecto en Django es una estructura simple que contiene un archivo de configuración (settings), urls, y una colección de aplicaciones Django. Éstas pueden ser aplicaciones escritas por ti mismo o aplicaciones de terceros que has decidido incluir en tu proyecto.

Configuración

Situado en PROYECTO/settings.py
Si estás utilizando un mecanismo de importación, por favor, utiliza from local_settings import * en la parte inferior de tu archivo settings.py

URLs

Situado en PROYECTO/urls.py
Debería contener la menor cantidad posible de lógica. Generalmente sólo debería apuntar a cada una de las configuraciones de urls (URLConfs) de tus aplicaciones específicas.

Estructura de proyecto propuesta

ejemplo.com/
    local_apps/
        Aplicaciones propias escritas para este proyecto (preferiblemente reusables, probablemente en tu PYTHONPATH)
    external_apps/
         Aplicaciones externas reusables que estás utilizando en este proyecto
         Nota: Estas aplicaciones también pueden estar en cualquier lugar en tu PYTHONPATH
    projects/
        dev_example/
        production_example/
        django96_example/
            manage.py, settings, urls, etc.
     docs/
        Aquí debe ir toda la documentación de tu proyecto
    static/
        - En producción esto estará en la raíz de tu MEDIA_URL
        css/
        js/
        images/
    tests/
        - Tests a nivel de proyecto (cada aplicación también debería tener tests)
    uploads/
        - Contiene imágenes, etc.
    templates/
        - Este area se utiliza para sobreescribir plantillas de tus aplicaciones reusables
        flatpages/
        comments/
        example/
        app1/
        app2/

Publicado por Antonio Melé el Martes 10 d Marzo d 2009 | 1 comentario | Categorías: convenciones

Feed RSS

Suscríbete a nuestro feed RSS y al feed de la comunidad para estar al tanto de todo lo que ocurre entorno a Django.

Proyectos

django-thumbs te permite crear miniaturas de imágenes con Django.

Escribe en el blog

Tú también puedes escribir en éste blog. Para hacerlo basta con que nos digas sobre qué quieres escribir un artículo relacionado con Django.

Entradas sobre "convenciones":

Convenciones de aplicaciones reusables en Django

¿Qué es una aplicación reusable?

¿Cómo puedo distribuir mi aplicación?

Modelos

URLs

Vistas

Admin

Plantillas

Otros bloques posibles

Documentación

Forms

Template tags

Sintaxis propuesta para template tags

Tests

Middleware

Context Processors

Managers

Feeds

Convenciones de proyecto en Django

Qué es un proyecto

Configuración

URLs

Estructura de proyecto propuesta

Feed RSS

Proyectos

Categorías

Escribe en el blog

Lo más leído

Recomendado