On Sat, 2009-03-07 at 21:29 -0800, Matt Doran wrote: > Hi there, > > I'm an experienced developer, but new to Django. I've experimented > with Django over the years, but I'm now in the process of planning a > medium sized Django app. We have an in-house support/email system > written in python, but it needs an overhaul. :) > > The application will become a simple CRM system, with the following > pieces: > * Email ticket tracking > * Simple Customer database > * Possible integration with order/licensing systems, etc. > * Some parts of the app will also have command-line scripts to handle > the integration with mail queues. So it's not a purely web-based app. > > I'd love some advice on structuring a project like this. In > particular the structure of applications/packages within the project.
The first two look like they could be separate applications, since they have no real dependencies on each other. Both depend on user management, at a minimum, the django.contrib.auth app, but you might also need to add some user management (and/or look at something like Pinax or one of the constituent components of that project for assistance). Command-line or web usage isn't really an application-level decision. That just specifies how things are executed. For command-line stuff, custom management commands are often useful, but there are a few approaches there (including settings.configure()) to set things up if you're using Django as a library in some other, larger system). > Django seems to encourage the creation of reusable "applications". Probably neither here nor there for you circumstances. It makes them possible, certainly. > When building a system like this, how does this apply? Do you simply > create a "project" with a single "application"? > > If so, then you end up with python package names like "mysite.myapp", > which seems kind of redundant in this case. You don't need to have "mysite" there all the time at all. You just have to be able to import things. So set up your Python path however you like to make the imports easiest. Generally, putting the mysite/ directory into the Python path is good advice, so that you can import apps just by directly using their names. > Is there a recommended best-practice approach to this type of > project? Or maybe even point me at a project that I can use as an > example. James Bennett's book (Practical Django Projects) gives a description of this sort of stuff. His talk at DjangoCon from last year (available via YouTube) isn't a bad place to start either. Only drawback of the book is that it was published pre-Django 1.0. All of the advice it contains is still 100% valid, but if you're needing actual code samples, the second edition (in preparation) is going to be more useful. > > Would there be any benefit of separating a system like this into > separate django "applications"? Are you likely to use any of the component pieces independently later? Would it be possible to test them in isolation, making development a little easier? This is really akin to the normal development decision making process of how do you split things up into separate files / modules and packages. You try to keep reasonably dependent things either together or having a one-way inheritance hierarchy (no loops). The idea is to keep the code as simple in self-contained blocks as possible so that you can maintain it easily in pieces later on. Small things are usually better, but 100's of small things is often worse than a dozen medium sized things, too. Best advice I can give is "don't overthink this"... As a general rule, my experience is that people worry a bit too much about splitting things into applications early on. The answer is to just pick something reasonable and start working. You can split it up later on if needs required. It's only once you start putting production data into things that shuffling models around becomes tricky (since you can't just drop your dev database or alter tables with gay abandon). Initially, it's probably better to try fleshing out the system and see if it feels comfortable. If it does, then it's a perfect working setup. If not, change something. > > PS: Whenever I've looked at Django ... I've found myself confused > about the concept of apps vs projects. What am I missing? Maybe > after developing with Django for a while it will all become clear. :) An "application" is, conceptually, anything that is reasonably self-contained and uses Django somewhere. It's a Python package that appears in the INSTALLED_APPS settings list. A "project" is a convenient wrapper particularly for those starting out. Ultimately, what you need to run a site are a settings file, a root URL Conf file and a bunch of applications that are available to be imported and thus sit somewhere on the Python path, as viewed by whatever is "running" Django -- meaning the webserver, usually. The applications don't have to reside anywhere near the settings file -- they just have to be importable. A bit more of a riff on this (taking it to extremes), is here: http://www.pointy-stick.com/blog/2007/11/09/django-tip-developing-without-projects/ (written by me about 18 months ago). If you're just starting out with Django, I'd ignore the stuff in there about minimal settings files and manage.py removal and stuff like that, at least initially. The early discussion on file organisation is the relevant bit here. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
