Ignacio tiene razón al señalar que algunas de las aplicaciones que menciona ya existen. También debe ver proyectos como Pinax para otras aplicaciones conectables que pueden ser un punto de partida para su propio proyecto.
Ahora a su pregunta: Un proyecto de Django es una colección de aplicaciones de Django, esa parte la tiene bien. El Django book define mejor:
"Un proyecto es un conjunto de configuraciones para una instancia de Django, incluyendo la configuración de base de datos, opciones específicas de Django y configuraciones específicas de la aplicación."
El django book defines a Django app como:
"Un haz de código Django, incluyendo modelos y puntos de vista, que vive juntos en un solo paquete Python y representa una aplicación completa Django"
Pero en una clase reciente con Jacob Kaplan-Moss entendí (cuenta que no estoy diciendo que es lo que dijo !!!) que una aplicación de Django es todo acerca de encapsular el comportamiento común bien definido. También entendí que teniendo muchas aplicaciones pequeñas está bien - mejor que tener una aplicación monolítica que hace de todo, y que algunas aplicaciones están ahí para proporcionar plantillas, algunas solo modelos, algunas una colección completa de plantillas, modelos y vistas .
La mayoría de mis proyectos, que son aplicaciones internas para nuestra empresa, tienen una aplicación común enchufable desarrollada internamente que es más o menos una colección de plantillas, css, javascript, etc .; que unen los proyectos con una apariencia común. No tengo vistas o modelos en esa aplicación conectable.
Tengo una aplicación enchufable, también desarrollada internamente, que alberga un grupo de modelos que se comparten entre varios proyectos. Los modelos representan tablas de bases de datos comunes que son utilizadas por varias aplicaciones diferentes y tenerlas duplicadas en cada una de las aplicaciones sería violate DRY.
Algunos buen ejemplo de aplicaciones:
- autenticación (Django ya tiene una aplicación estándar de autenticación)
- apoyo gravatar (Pinax lo tiene)
- etiquetado (Varias opciones disponibles, Pinax tiene uno)
- servicio de asistencia (que desarrolló uno internamente)
Todo lo anterior está abordando un problema lógico. No intentan ser una solución completa (hágalo todo) ... La aplicación Gravatar no proporciona soporte OpenID (hay otra aplicación para OpenID), y la aplicación interna de mi servicio de ayuda no proporciona autenticación (usa el django predeterminado). aplicación para eso).
Un mal ejemplo de una aplicación de Django sería aquella que implementó autenticación, soporte de apertura, servicio de asistencia y seguimiento de proyectos. ¿Por qué sería eso malo? Porque ahora si quieres reutilizar tu aplicación de autenticación, tienes que extraer algunos modelos, algunas vistas y algunas plantillas de tu aplicación que lo abarca todo. Si decide que el soporte de OpenId es imprescindible para su próximo proyecto, tendrá que pasar por el código de este gigante de una aplicación y descubrir qué partes son relevantes.
Una buena aplicación Django proporciona un conjunto lógico de operaciones y lo hace bien.
La autenticación del usuario, el etiquetado y los comentarios ya son aplicaciones separadas en Django. –
Mientras espera respuestas más autorizadas, puede interesarle explorar el código fuente de Satchmo (http://www.satchmoproject.com/), una tienda en línea basada en Django. Si bien no he buceado en la fuente, al menos está en el mismo dominio que su proyecto. También vale la pena mirar la fuente de Everyblock (http://code.google.com/p/ebcode/), ya que fue escrita en parte por Adrian Holovaty, cocreador de Django. Hay pocas formas mejores de entender las expresiones idiomáticas en torno a las herramientas que ver cómo los usan sus creadores. – Callahad