¿Qué es para dejar de usar myproduct.myproduct? Lo que necesita para lograr eso consiste aproximadamente en hacer esto:
django-admin.py startproject myproduct
cd myproduct
mkdir myproduct
touch myproduct/__init__.py
touch myproduct/models.py
touch myproduct/views.py
y así. ¿Ayudaría si dijera views.pyque no tiene que ser llamado views.py? Siempre que pueda nombrar, en la ruta de Python, una función (generalmente package.package.views.function_name) que se manejará. Simple como eso. Todas estas cosas de "proyecto" / "aplicación" son solo paquetes de Python.
Ahora, ¿cómo se supone que debes hacerlo? O más bien, ¿cómo podría hacerlo? Bueno, si se crea una pieza importante de la funcionalidad reutilizable, como decir un editor de marcado, que es cuando se crea una "aplicación de nivel superior" que podría contener widgets.py, fields.py, context_processors.pyetc - todas las cosas que usted puede ser que desee importar.
Del mismo modo, si puede crear algo como un blog en un formato que es bastante genérico en todas las instalaciones, puede envolverlo en una aplicación, con su propia plantilla, carpeta de contenido estático, etc., y configurar una instancia de un proyecto django para usarlo contenido de la aplicación
No existen reglas estrictas que indiquen que debe hacer esto, pero es uno de los objetivos del marco. El hecho de que todo, incluidas las plantillas, le permite incluir desde una base común significa que su blog debe encajar perfectamente en cualquier otra configuración, simplemente cuidando su propia parte.
Sin embargo, para abordar su preocupación real, sí, nada dice que no pueda trabajar con la carpeta de proyecto de nivel superior. Eso es lo que hacen las aplicaciones y puedes hacerlo si realmente quieres. Sin embargo, tiendo a no hacerlo por varias razones:
- La configuración predeterminada de Django no lo hace.
- A menudo, quiero crear una aplicación principal, así que creo una, generalmente llamada
website. Sin embargo, en una fecha posterior me gustaría desarrollar una funcionalidad original solo para este sitio. Con el fin de hacerlo extraíble (ya sea que lo haga o no), tiendo a crear un directorio separado. Esto también significa que puedo eliminar dicha funcionalidad simplemente desvinculando ese paquete de la configuración y eliminando la carpeta, en lugar de eliminar un complejo las URL correctas de una carpeta global urls.py.
- Muy a menudo, incluso cuando quiero hacer algo independiente, necesita un lugar para vivir mientras lo cuido / lo hago independiente. Básicamente el caso anterior, pero para cosas que tengo la intención de hacer genérico.
- Mi carpeta de nivel superior a menudo contiene algunas otras cosas, que incluyen, entre otras, scripts wsgi, scripts sql, etc.
- Las extensiones de administración de django se basan en subdirectorios. Por lo tanto, tiene sentido nombrar los paquetes de manera adecuada.
En resumen, la razón por la que hay una convención es la misma que cualquier otra convención: ayuda cuando se trata de que otros trabajen con su proyecto. Si lo veo fields.py, inmediatamente espero que el código en él subclasifique el campo de django, mientras que si lo veo inputtypes.py, podría no ser tan claro sobre lo que eso significa sin mirarlo.