Hi Malcolm, Thanks for the very detailed (and well thought-out) response! Greatly appreciated.
On Mar 8, 4:57 pm, Malcolm Tredinnick <malc...@pointy-stick.com> wrote: > On Sat, 2009-03-07 at 21:29 -0800, Matt Doran wrote: > > > 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. > Thanks, I'll take a look at it. > > > > Would there be any benefit of separating a system like this into > > separate django "applications"? > > > 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. > Sound like the way to go. > > > > 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. :) > > 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-wit...(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. That article was fanstastic!! It really cleared up my understanding of how things work. It seems that something along these lines should be explained or pointed to in the Django tutorial/docs. The whole "startproject" thing and the default layout feels like it's forcing me to make decisions that I'm not ready to (i.e. it's on page 1 of the tutorial). I guess experienced developers usually ask at this point "why do I need to do it this way?", "what compromises am I making?", "will I regret these decisions later?". Armed with the info in your article, I feel much more comfortable about just jumping in ... or choosing an alternate project layout. Thanks again! Matt --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
