Project design / FS layout for large django projects [closed]

Question!

What is the best way to layout a large django project? The tutorials provide simple instructions for setting up apps, models, and views, but there is less information about how apps and projects should be broken down, how much sharing is allowable/necessary between apps in a typical project (obviously that is largely dependent on the project) and how/where general templates should be kept.

Does anyone have examples, suggestions, and explanations as to why a certain project layout is better than another? I am particularly interested in the incorporation of large numbers of unit tests (2-5x the size of the actual code base) and string externalization / templates.

By : rcreswick


Answers


I really like Randall Degges' post on this subject. He leaves out info on how to glue the settings files together, but I'll have a post on that I'll be able to link, but for now anyone can check out my repo where I include some direction in the readme.



This page does a good job of addressing some of my questions: http://www.b-list.org/weblog/2006/sep/10/django-tips-laying-out-application/

Specifically:

  1. To define custom template tags or filters, you must create a sub-directory in the application’s directory called templatetags, and it must contain a file named __init__.py so that it can be imported as a Python module.
  2. To define unit tests which will automatically be noticed by Django’s testing framework, put them in a module called tests (which can be either a file named tests.py or a directory called tests). The testing framework will also find any doctests in that module, but the preferred place for those is, of course, the docstrings of the classes or functions they’re designed to test.
  3. To provide custom SQL which will be executed immediately after your application is installed, create a sub-directory called sql inside the application’s directory; the file names should be the same as the names of the models whose tables they’ll operate on; for example, if you have an app named weblog containing a model named Entry, then the file sql/entry.sql inside the app’s directory can be used to modify or insert data into the entries table as soon as it’s been created.

The note about tests.py and tests (the directory) also holds for models, which helps address the problem of having way to many tests (or models) for one file.

I would still like to see some examples / suggestions for app/project break down, and big django sites that work well.

By : rcreswick


This video can help you solving your question :)
By: admin