Be aware, the below structure works perfectly for us because of trial and error from years of development, it suits the particular style/nature of our projects, and it has been made standardized across the board. I wouldn't recommend using the above, instead, I would recommend looking around for different approaches (like you have in this thread) and see which feels "right". I'd say you'll probably change your structure/approach at least 3-4 times before you find one that feels absolutely right.
Personally, we use the following structure: project/ - root project directory project/libs - place to hold shared libs project/apps - place where your 'apps' are held (these will go into INSTALLED_APPS) project/apps/app1 - some application project/apps/app1/models.py - models for app1 project/apps/app2 - some application project/apps/app2/models.py - models for app2 project/sites/bwebsite/ project/sites/bwebsite/views.py - views for bwebsite project/sites/bwebsite/urls.py - urls for bwebsite project/sites/awebsite/ project/sites/awebsite/views.py - views for awebsite project/sites/bwebsite/urls.py - urls for bwebsite The above then works in conjunction with MultihostMiddleware ( https://code.djangoproject.com/wiki/MultiHostMiddleware ). As well as this, we heavily use db routers to allow us to communicate with legacy databases in an ORM style, but would never require views, so it makes sense for us to use this approach. An example use case for the above would be something like; Telecommunications website, requires public website, customer portal and staff backend - however you want to keep the views/urls/apis separate, plus some of them share functionality within the models. This allows you to keep the concept of individual sites completely separate from the models. Hope this helps a bit! Cal On Tue, Sep 11, 2012 at 10:56 PM, Matthew Woodward <m...@mattwoodward.com>wrote: > Hi all -- semi-new to Django but learning fast and enjoyed meeting a lot > of folks at DjangoCon last week! I have some basic project setup and > terminology questions I'm hoping to get some thoughts on. > > Basically I'm curious as to the convention about creating a project using > virtualenv and then adding applications to the project in terms of where > the files are placed. I'll just go through what I've been doing and I'd > welcome any and all feedback as to where I'm breaking with conventional > wisdom. > > Let's say I'm starting a new project foo and run this from a ~/projects > directory: > virutalenv foo > > So at that point I have ~/projects/foo I then cd into that directory, > activate that virtualenv, and install Django > cd ~/projects/foo > source bin/activate > bin/pip install django > > I then start the Django project from ~/projects/foo: > bin/django-admin.py startproject foo > > At that point I have ~/projects/foo/foo for my project directory, and in > there it puts another foo for the foo application (I'm assuming that's > accurate terminology? or is that the "project" since that's where > settings.py lives?). > > So it's clear what I have at this point: > ~/projects/foo <-- root virtualenv directory containing bin, include, etc. > ~/projects/foo/foo <-- root project directory containing manage.py and foo > application (or is it called project?) directory > ~/projects/foo/foo/foo <-- foo application (project?) directory containing > settings.py, etc. > > If that's correct thus far (and please let me know if not!), my next > question is where to create additional applications. I'm assuming that in > this case if I want to create a bar app I cd into ~/projects/foo/foo and > run: > python manage.py startapp bar > > So that that point I have: > ~/projects/foo/foo/foo <-- where settings.py lives > ~/projects/foo/foo/bar <-- bar application files (models.py, etc.) > > Specifically on this last piece, should I be creating things there or is > the convention to put applications in the same directory as settings.py, so > you wind up with your application directories at the same level as > settings.py? E.g.: > ~/projects/foo/foo/foo <-- where settings.py lives > ~/projects/foo/foo/foo/bar <-- bar application files > > It certainly works fine the way I'm doing it as long as I reference the > location of the application files correctly, but in a lot of the books I've > been reading application files would be referenced using this example as > 'foo.bar' instead of just 'bar' which is what I wind up with the way I've > been doing things. > > Any thoughts/pointers/admonitions/etc. are greatly appreciated. > > Thanks, > Matt > > -- > Matthew Woodward > m...@mattwoodward.com > http://blog.mattwoodward.com > identi.ca / Twitter: @mpwoodward > > Please do not send me proprietary file formats such as Word, PowerPoint, > etc. as attachments. > http://www.gnu.org/philosophy/no-word-attachments.html > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-users@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
