用于新的Django 1.4项目结构的用例 [英] Use cases for new Django 1.4 project structure?

问题描述

我想这是一个后续的问题，我应该在django 1.4中创建django应用程序？最终的答案似乎是没有人知道为什么Django改变了项目结构 - 这似乎不太令人满意。

我们正在启动一个新的Django项目，目前我们正在遵循 http://www.deploydjango.com/django_project_structure/index.html ：

 ├──项目
│├──应用程序
││├──app1 
││└──app2 
│├──libs 
││├──lib1 
││└──lib2 
│├──settings.py 
│├──urls.py 
│└──wsgi.py 
└──管理。 py 
  

但是我想我们也期待着一个多开发人员的环境，其中大部分是具有共同的项目级组件的独立应用程序，所以看起来我更清楚了分离项目和应用路径。

 ├──项目
│├──settings.py 
│├──urls.py 
│└──wsgi。 py 
├──应用程序
│├──app1 
│└──app2 
├──libs 
│├──lib1 
│└ ──lib2 
└──manage.py 
  

很难想出任何具体的但是，这种非风格的理由。 （我以前主要是使用单应用程序项目，所以我可能会在这里遗漏一些东西。）

主要是因为Django 1.4似乎在后面的方向发展。我假设有一些理由或预期的用例促成了这种变化，但我只看到了可能的猜测。

问题：

1. 1.4项目结构更改的动机是什么？


2. 是否有用例在项目内部/外部的应用程序会产生不平凡的影响？

解决方案

1. 从项目中提取应用程序更容易，因为没有更多导入：

     from projectname.appname.models import MyModel 
     

   而不是像导入应用一样导入它们通过python包安装




2. 如果您使用i18n，那么这可能会产生影响，因为makemessages在当前目录中搜索翻译字符串。使用单个.po文件翻译应用程序和项目的好方法是在项目目录外创建区域设置文件夹

    ├ ──项目
   │├──settings.py 
   │├──urls.py 
   │└──wsgi.py 
   ├──app1 
   ├─ ─app2 
   ├──locale 
   │├──en 
   │└──de 
   └──manage.py 
     / pre> 

I guess this is sort of a followup question to Where should i create django apps in django 1.4? The final answer there seemed to be "nobody knows why Django changed the project structure" -- which seems a bit unsatisfactory.

We are starting up a new Django project, and currently we are following the basic structure outlined at http://www.deploydjango.com/django_project_structure/index.html:

├── project
│   ├── apps
│   │   ├── app1
│   │   └── app2
│   ├── libs
│   │   ├── lib1
│   │   └── lib2
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
└── manage.py

But I think we also are anticipating a multi-developer environment comprising largely independent applications with common project-level components, so it seems cleaner to me to separate out the project and app paths.

├── project
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
├── apps
│   ├── app1
│   └── app2
├── libs
│   ├── lib1
│   └── lib2
└── manage.py

It's hard to come up with any specific, non-stylistic rationale for this, though. (I've mostly worked only with single-app projects before now, so I may be missing something here.)

Mainly, I'm motivated by the fact that Django 1.4 seems to be moving in the latter direction. I assume there is some rationale or expected use case that motivated this change, but I've only seen speculation on what it might be.

Questions:

1. What was the motivation for the 1.4 project structure change?
2. Are there use cases where having apps inside/outside of the project makes a non-trivial impact?

解决方案

1. It's much easier to extract an app from a project because there are no more imports like this:

   from projectname.appname.models import MyModel
   

   instead you import them the same way you would import apps which are installed via a python package

2. if you use i18n then this could make an impact because makemessages searches for translation strings in the current directory. a good way to translate apps and the project using a single .po file is to create the locale folder outside the project dir

   ├── project
   │   ├── settings.py
   │   ├── urls.py
   │   └── wsgi.py
   ├── app1
   ├── app2
   ├── locale
   │   ├── en
   │   └── de
   └── manage.py
   

这篇关于用于新的Django 1.4项目结构的用例的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！