On 9/6/07, Adam Jenkins <[EMAIL PROTECTED]> wrote: > This actually brings up an issue. I've heard that many Django developers > don't > use projects at all, that they just use apps. Is this correct? Should I > default to one > project and break it up into smaller ones if the need arises?
First off, be very careful about how you use the terms; you cannot use Django on the Web without a "project". A "project", in its absolute bare minimum form, is a settings module and a root URLConf module; applications *cannot* supply these things, and without them Django cannot be used to serve anything. An application supplies models, optionally some views, template tags, etc. The question, then, is not "do I use a project?", because you *must* have a project in order to have settings and a root URLConf. Where people's opinions vary is on how to organize the applications used within the project -- the things listed in the project's INSTALLED_APPS setting. The question, in a nutshell, is whether the applications should be developed inside the project's directory (and hence be forever coupled to it), or be developed as standalone Python modules in their own right (and hence can be used in multiple projects simultaneously, or distributed independently of the project(s) which originally used them). The Django tutorial shows how to build an application which lives completely within the project's directory, and hence is absolutely coupled to the project (unless you fiddle with your Python import path, the only way to access code in the application is to include the project's name in the import statement). This is fine for a quick "getting started"-style document like the tutorial, where explaining anything else would complicate things unnecessarily, but for any sort of production application it should be avoided. The alternative is to develop applications as normal Python modules which live on your Python import path, and to treat the project simply as a bit of "glue" which binds them all together with appropriate settings. This is vastly preferable because it means these applications can be re-used independently of the project. Perhaps some folks can swear that the code in their apps will never be re-used by anyone at any point for the rest of eternity, but I can't and so I don't couple my applications to specific projects. As for your question about databases: Django currently only supports using one database at a time, as evidenced by the fact that the settings file only lets you specify one database. My advice to you would be to replace the existing segregated applications one at a time with Django applications -- you can create separate "projects", each using one or two of the applications -- and then, once you're ready to consolidate, use Django's 'manage.py dumpdata' command to serialize all that data out, create one project with one database which will use all the apps, and use 'manage.py loaddata' to pull all that data into it. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
