Django Web Framework: The 'D' is silent dumbass

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Django Web Framework: The 'D' is silent dumbass

«‹›122 »

bitprophet: Jul 22, 2004; Taco Defender

JammyB posted:

I'm looking for a little advice on deploying some Django websites to an Ubuntu Server. Where exactly should each website live within the file structure?

I tend to follow a convention I first saw over in the Rails world and put things in /srv/django, e.g. /srv/django/example.com, /srv/django/example2.com and so forth.

Prior to this I did the same thing but with /opt instead of /srv; the two are largely interchangeable in my view, though the various filesystem hierarchy standards may disagree. Basically, any code or files that the server is "serving up" and doesn't have a predetermined, obvious location -- I'll stick into /srv/ somewhere, and that includes stuff like Django/Rails/etc Web application project folders.

Home directories are never, in my opinion, the right place to put anything except personal poo poo that has nothing to do with the actual server's mode of operation. It's just gross

Another bad choice is /var/www/sitename, as /var/www/ and/or its subdirectories are for Apache docroots and you never want to put non-CGI-ish code (i.e. PHP, actual CGI scripts, static files etc) into a place that could be served up by your Web server.

However, it may be a good idea to symlink a subdirectory of your Django project into a Web docroot -- for example, I tend to have a Django project directory structure like this:

code:

example.com
|-- __init__.py
|-- app.wsgi
|-- manage.py
|-- media
|   |-- css
|   |   |-- print.css
|   |   `-- screen.css
|   |-- img
|   |   |-- foo.jpg
|   |   `-- bar.png
|   `-- js
|       |-- main.js
|       `-- datepicker.js
|-- app1
|  `-- [app stuff here]
|-- app2
|  `-- [ditto]
|-- app3  
|  `-- [ditto]
|-- settings.py
`-- urls.py

and then symlink the media directory (which would be in /srv/django/example.com/media) as, say, /var/www/example.com (so that the Web server can see e.g. /var/www/example.com/js/. This lets Apache serve my static media while keeping the Python out of the docroot and keeping the Python and media files together in one (source controlled) directory structure. (And since this approach is flexible, it can change to accommodate whatever URL structure you want to appear.)

bitprophet fucked around with this message at 01:11 on Sep 8, 2009

# ? Sep 8, 2009 01:08

Adbot: ADBOT LOVES YOU

# ? May 19, 2024 00:45

geera: May 20, 2003

bitprophet posted:

code:

example.com
...
|-- app1
|  `-- [app stuff here]
|-- app2
|  `-- [ditto]
|-- app3  
|  `-- [ditto]
...

This may have been asked/discussed before, but how do you approach organizing the "main" part of the website in your code? Do you make an app and call it something like "site" or "main" or whatever, and put the majority of your work in that app's directory, or do you have some other method?

# ? Sep 8, 2009 13:44

bosko: Dec 13, 2006

geera posted:

This may have been asked/discussed before, but how do you approach organizing the "main" part of the website in your code? Do you make an app and call it something like "site" or "main" or whatever, and put the majority of your work in that app's directory, or do you have some other method?

Most people do exactly just that. Create a basic main/site/misc app directory for all those extra pages.

You will find when you develop a Django website your mind will categorize the site into some useful categories though and end up simply using the flatpages module for those extra few pages.

# ? Sep 8, 2009 15:19

JammyB: May 23, 2001; I slept with Mary and Joseph never found out

Thanks MonkeyMaker and bitprophet. The guide is excellent though quite a bit more advanced than I want to aim for at the moment, but it's food for thought as I hadn't even considered things like the virtual environments. Cheers.

# ? Sep 8, 2009 18:41

bitprophet: Jul 22, 2004; Taco Defender

geera posted:

This may have been asked/discussed before, but how do you approach organizing the "main" part of the website in your code? Do you make an app and call it something like "site" or "main" or whatever, and put the majority of your work in that app's directory, or do you have some other method?

What bosko said. Personally, I tend to make a "base" app, which often has no models, views or URLs and is just there for stuff like context managers and custom templatetags and such -- keeping these in an "app" allows Django's app-centric loaders to pick them up correctly.

I sometimes also throw "top level" crap (e.g. the homepage URL/view/template of a multi-app site, etc) into this app as well, though. Keeps the top level directory a bit neater. If I go too far down that road I'll even put my settings.py and top level urls.py in this folder too -- since you can just set your DJANGO_SETTINGS_MODULE to 'myproject.base.settings' without issue -- but that might be a bit much, still on the fence myself as to whether it's really worth it.

# ? Sep 8, 2009 20:08

checkeredshawn: Jul 16, 2007

I have a model and one of the fields is a DateField. In the admin interface, when the list_filter variable contains that field, the filter display on the right-hand side only display these:

* Any date
* Today
* Past 7 days
* This month
* This year

Is there any way to have it filter by future dates? For example:

* Any date
* Today
* Next 7 days
* Next month
* Next year

Any input is appreciated

Edit: Just found date_hierarchy, that's pretty cool, but I'm still curious if the list_filter thing is possible.

checkeredshawn fucked around with this message at 21:28 on Sep 16, 2009

# ? Sep 16, 2009 21:25

king_kilr: May 25, 2007

No list_filter currently doesn't support that. If and when I ever update django-filter for using in ModelAdmins you will be able to

# ? Sep 16, 2009 22:36

MonkeyMaker: May 22, 2006; What's your poison, sir?

Got a problem that's been screwing me over for a day now.

I'm using django-tagging to tag models on a site. Right now there are a few different models that are tagged with common tags (e.g. Video and Collection could both have the tag 'cheese'). I need to get a list of all of the tags across all models, ordered by popularity (how often they're used, of course). That's where you come in. Any help?

Nevermind, I got it. For those interested:

code:

num_tags = TaggedItem.objects.values('tag__name').annotate(
        tcount=Count('tag')
    ).order_by('-tcount')

MonkeyMaker fucked around with this message at 00:36 on Sep 17, 2009

# ? Sep 17, 2009 00:11

reksio: Feb 5, 2007

I'm currently still having some issues setting up the online questionnaire application I've been trying to get running properly with little success, so I thought I would just ask if any django developers here would be willing to help me work on hacking some functionality into my program.

This isn't for a for-profit venture, as it's going to be used for a research project for my own and my university's psychology department; but I would be able to pay for the help but I'm honestly not sure what going rate would be and I don't anticipate the hack I need requiring a lot of work.

I would just post on djangogigs.com, but I am looking for somebody who could chat with me and hopefully explain how to fix the hole in functionality I have and not for somebody to just knock out the code. It is a pretty basic django issue with cookies, user id and databasing but it would be a wall of text to post in this thread.

I thought I would post this request in SA-Mart, but I figured that nobody would see it so maybe somebody with some free time will find it here. If anybody here is interested, I would be very grateful if you could just respond here or contact me by e-mail. My address is fewquestions (at) me.com.

# ? Sep 18, 2009 03:09

king_kilr: May 25, 2007

If you post your actually question here it would be pretty useful

However in any event I'll refer you to my slides from EuroDjangocon where one of the topics I cover is building a survey application: http://www.slideshare.net/kingkilr/forms-getting-your-moneys-worth

# ? Sep 18, 2009 03:11

Janitor Prime: Jan 22, 2004; PC LOAD LETTER

What da fuck does that mean; Fun Shoe

If you still want some help hit me up at hiro2k at gmail. I've done quite a few things like this before.

# ? Sep 18, 2009 04:40

spencer for hire: Jan 27, 2006; we just want to dance here, someone stole the stage
they call us irresponsible, write us off the page

In case anyone cares, the problem I was having earlier:

spencer for hire posted:

Anyone have experience customizing the comments framework?

but I can't figure out to render my new CommentFormWithTitle. The documentation is kind of sparse (or this is way out of my league to be messing around with).

was because I didn't upgrade to 1.1. I didn't even think to check that I was following the wrong documentation. I feel stupid for wasting a few hours.

# ? Sep 19, 2009 20:03

Cpt.Wacky: Apr 17, 2005

Can anyone recommend some material on best practices for easily managing development, testing, and production environments?

# ? Sep 21, 2009 21:06

king_kilr: May 25, 2007

Cpt.Wacky posted:

Can anyone recommend some material on best practices for easily managing development, testing, and production environments?

Checkout Brian Rosner's slides from DjangoCon on Django deployment: http://bit.ly/deploying-django

# ? Sep 21, 2009 21:49

Cpt.Wacky: Apr 17, 2005

Thanks, that's something to get started at least. It's kind of hard to follow since it's so terse, but I gathered that I can do something with a combination of pip, virtualenv and fabric. I'm guessing the tolkien thing mentioned at the end is something the presenter developed and hasn't been released yet?

I think for my situation virtualenv would probably be enough if I can find the time to sit down and figure it out.

If there's anything more detailed on deployment I'd love to see it.

# ? Sep 22, 2009 18:45

king_kilr: May 25, 2007

Cpt.Wacky posted:

Thanks, that's something to get started at least. It's kind of hard to follow since it's so terse, but I gathered that I can do something with a combination of pip, virtualenv and fabric. I'm guessing the tolkien thing mentioned at the end is something the presenter developed and hasn't been released yet?

I think for my situation virtualenv would probably be enough if I can find the time to sit down and figure it out.

If there's anything more detailed on deployment I'd love to see it.

Yes, Tolkein is an internal system at Eldarion (where Brian works and I contract).

# ? Sep 22, 2009 23:26

Pie Colony: Dec 8, 2006; I AM SUCH A FUCKUP THAT I CAN'T EVEN POST IN AN E/N THREAD I STARTED

I have a custom tag {% vote "292" %} or whatever. Basically inside the code for the tag it checks whether the ID (292) meets some criteria. If it does, I want it to render x template, if it doesn't, I want it to render y.

I'm having trouble with the rendering part. I have this as my test code right now:

code:

def render(self, context):
		return render_to_response('vote/vote_detail.html', {}, context_instance=context)

The problem is on my normal page, this adds a line "Content-Type: text/html; charset=utf-8" before the actual vote_detail.html. How do I get rid of this?

# ? Sep 23, 2009 19:49

No Safe Word: Feb 26, 2005

Pie Colony posted:

I have a custom tag {% vote "292" %} or whatever. Basically inside the code for the tag it checks whether the ID (292) meets some criteria. If it does, I want it to render x template, if it doesn't, I want it to render y.

I'm having trouble with the rendering part. I have this as my test code right now:
code:
def render(self, context):
		return render_to_response('vote/vote_detail.html', {}, context_instance=context)
The problem is on my normal page, this adds a line "Content-Type: text/html; charset=utf-8" before the actual vote_detail.html. How do I get rid of this?

render_to_response returns an HttpResponse, if I recall correctly, custom template tags should just return a string. If you want it to basically load a template and render that then you'll have to create a Template with that path and call .render() and return that. Something like:

code:

def render(self, context):
   t = Template('vote/vote_detail.html', {})
   return t.render(context)

e: warning, untested code :siren:

No Safe Word fucked around with this message at 20:08 on Sep 23, 2009

# ? Sep 23, 2009 20:05

Pie Colony: Dec 8, 2006; I AM SUCH A FUCKUP THAT I CAN'T EVEN POST IN AN E/N THREAD I STARTED

I got it working with

code:

	def render(self, context):
		t = loader.get_template('vote/vote_detail.html')
		return t.render(context)

Thanks.

# ? Sep 23, 2009 20:32

king_kilr: May 25, 2007

Checkout django.template.loaders.render_to_string.

# ? Sep 23, 2009 21:18

MonkeyMaker: May 22, 2006; What's your poison, sir?

I'm also trying to do a template tag, but it's apparently more complex than I can handle.

Here's a pastie of the current code: http://pastie.org/628219

I have Locations that lots of things belong to. If you're on a page whose things belong to a Location, and there's a header for that location, you should see that special header. Otherwise, you should get a random header. If your location doesn't have a header associated, it also needs to check your location's parents until it either hits one with a header or one with no parent (it would then show a random one like before).

Any help or have I horribly confused you all?

BTW, if I'm doing things completely retarded, let me know. Unfortunately the header thing is a client requirement so I doubt I can just trash it.

MonkeyMaker fucked around with this message at 02:06 on Sep 24, 2009

# ? Sep 24, 2009 01:57

king_kilr: May 25, 2007

looks like I forgot to announce it, but DjangoDose (the successor to This Week in Django) is now on the air: http://djangodose.com/ Enjoy the content and if you ever have any ideas for stuff to put on the show please either send us feedback or leave a message here!

# ? Sep 29, 2009 05:09

king_kilr: May 25, 2007

Critical Django Security Release: http://www.djangoproject.com/weblog/2009/oct/09/security/

# ? Oct 9, 2009 23:32

SlightlyMadman: Jan 14, 2005

bitprophet posted:

I tend to follow a convention I first saw over in the Rails world and put things in /srv/django, e.g. /srv/django/example.com, /srv/django/example2.com and so forth.

Prior to this I did the same thing but with /opt instead of /srv; the two are largely interchangeable in my view, though the various filesystem hierarchy standards may disagree. Basically, any code or files that the server is "serving up" and doesn't have a predetermined, obvious location -- I'll stick into /srv/ somewhere, and that includes stuff like Django/Rails/etc Web application project folders.

Home directories are never, in my opinion, the right place to put anything except personal poo poo that has nothing to do with the actual server's mode of operation. It's just gross

Another bad choice is /var/www/sitename, as /var/www/ and/or its subdirectories are for Apache docroots and you never want to put non-CGI-ish code (i.e. PHP, actual CGI scripts, static files etc) into a place that could be served up by your Web server.

However, it may be a good idea to symlink a subdirectory of your Django project into a Web docroot -- for example, I tend to have a Django project directory structure like this:
code:
example.com
|-- __init__.py
|-- app.wsgi
|-- manage.py
|-- media
|   |-- css
|   |   |-- print.css
|   |   `-- screen.css
|   |-- img
|   |   |-- foo.jpg
|   |   `-- bar.png
|   `-- js
|       |-- main.js
|       `-- datepicker.js
|-- app1
|  `-- [app stuff here]
|-- app2
|  `-- [ditto]
|-- app3  
|  `-- [ditto]
|-- settings.py
`-- urls.py
and then symlink the media directory (which would be in /srv/django/example.com/media) as, say, /var/www/example.com (so that the Web server can see e.g. /var/www/example.com/js/. This lets Apache serve my static media while keeping the Python out of the docroot and keeping the Python and media files together in one (source controlled) directory structure. (And since this approach is flexible, it can change to accommodate whatever URL structure you want to appear.)

I really like this scheme, and have adopted it for a new project I just set up. Where do you keep your templates? I'm going to put them in /srv/django/example/templates, but I was curious if you had an opinion on that.

# ? Oct 19, 2009 22:16

bitprophet: Jul 22, 2004; Taco Defender

SlightlyMadman posted:

I really like this scheme, and have adopted it for a new project I just set up. Where do you keep your templates? I'm going to put them in /srv/django/example/templates, but I was curious if you had an opinion on that.

Huh, I totally omitted templates in that example. Probably because the project I was basing it on uses per-app template loading (see the 2nd-mentioned loader type in that section.) I don't do as much Django lately as I'd like, but when I was last setting up new projects I did lean in that direction (per-app template folders.)

While you have to name templates globally unique names, or else stick them into silly subfolders (i.e. root/app1/templates/app1/blah.html, referred to as "app1/blah.html" in the code just like with project-wide templates) it still means that your individual apps can be broken out, given to someone else, or otherwise packaged nicely. (king_kilr, has anyone done any interesting work in this area recently?)

Anyway, project-wide templates aren't bad per se -- my single biggest Django app does it, though that's mostly a function of its age -- just slightly less flexible in terms of future refactoring of apps.

# ? Oct 20, 2009 01:21

duck monster: Dec 15, 2004

Its probably worth pointing out if you are not the sysadmin of the box, installing apps in /srv or /django or any other such top level directory will deeply annoy most sysadmins, because its funadamentally at odds with the posix scheme and I might you run the risk of breaking your backup plans if you have those cheap vhost backups that just backup /etc /home /opt and /var (or whatever)

A lot of the better datacenter setups have funky arangements that put 'static' and 'not so static' directories in different SAN clusters that will have different approaches to raid and backups to optimise for read vs write (ie slow writes on USR , /tmp stays on local blade and /var might have something thats a bit more balanced between read and writes

duck monster fucked around with this message at 16:52 on Oct 20, 2009

# ? Oct 20, 2009 16:47

sink: Sep 10, 2005; gerby gerb gerb in my mouf

This could be a very general purpose question that exists outside of Django but since I'm using that framework I figured I'd ask here.

I would like to know if in general it's wise to push conditional statements downward into the database layer so that when checking fields I get a zero length result set. I will give you an example.

code:

#I could do obnoxious conditionals like this:

myobject = MyTable.objects.get(id=42)
if not myobject.user != user or myobject.some_field != required_value: return "BAD BAD BAD"

# or I could it like this:

queryset = MyTable.objects.filter(id=42, user=myuser, some_field=required_value)
if not queryset.count(): return "BAD BAD BAD"

Pushing the conditionals into the database seems much nicer than doing the conditionals in Python.

I am mostly looking for conventional wisdom on changing to this style. I asked this in #django on freenode and this guy rozwell, who seems to usually be pretty cool, spazzed out at me for half an hour about why it doesn't matter. I think it might matter some of the time.

# ? Oct 20, 2009 19:18

king_kilr: May 25, 2007

Personally I like pushing stuff down to the DB level. That's why I filed this ticket http://code.djangoproject.com/ticket/11402 . I'll upload a patch for it any day now.

# ? Oct 20, 2009 21:16

bitprophet: Jul 22, 2004; Taco Defender

duck monster posted:

installing apps in /srv or /django or any other such top level directory will deeply annoy most sysadmins [...]

I'm lucky enough to admin my own systems and/or generally work in environments where the sysadmin is actually told what the system will be used for and can tailor the backup/mount scheme accordingly. (I also tend to use a one-big-partition setup unless the system has obvious needs otherwise, because I've run into other peoples' poor partition size planning way more often than I run into situations involving SANs or needing specific mount flags. v :shobon:

v yes I work in a small/medium sized web shop, how'd you guess?)

Out of curiosity, where would a POSIX or LFHS compliant location for "web apps" like this be? Please don't say something horrid like /home/django/myapp :cry:

I'm guessing /var/django/myapp or /opt/django/myapp?

bitprophet fucked around with this message at 21:50 on Oct 20, 2009

# ? Oct 20, 2009 21:43

deimos: Nov 30, 2006; Forget it man this bat is whack, it's got poobrain!

bitprophet posted:

I'm lucky enough to admin my own systems and/or generally work in environments where the sysadmin is actually told what the system will be used for and can tailor the backup/mount scheme accordingly. (I also tend to use a one-big-partition setup unless the system has obvious needs otherwise, because I've run into other peoples' poor partition size planning way more often than I run into situations involving SANs or needing specific mount flags. vv yes I work in a small/medium sized web shop, how'd you guess?)

Out of curiosity, where would a POSIX or LFHS compliant location for "web apps" like this be? Please don't say something horrid like /home/django/myapp I'm guessing /var/django/myapp or /opt/django/myapp?

The correct place for that stuff IS /srv according to the LFHS.

http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/srv.html

deimos fucked around with this message at 22:48 on Oct 20, 2009

# ? Oct 20, 2009 22:45

bitprophet: Jul 22, 2004; Taco Defender

deimos posted:

The correct place for that stuff IS /srv according to the LFHS.

http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/srv.html

VINDICATION

I thought there was some reason I moved to /srv from /opt, other than "well that's how the rails guys at work do it". Maybe I actually looked it up :v:

(No, I don't remember these things very well.)

duck monster's point may still hold for non Linux systems, though, but that doesn't describe me so eh.

# ? Oct 21, 2009 00:56

SlightlyMadman: Jan 14, 2005

Awesome, I'm glad I listened to you advice, bitprophet! And yes, I'm putting application subdirectories is my project/templates directory (even though I only have two apps at the moment).

The scheme is working out really well, as before I had three directories in /home; projects, templates, and sites (for django, templates, and static files). It was horrible and ugly and a pain in the rear end to switch between. Now I can just cd into my project directory and access everything as well as being local to my manage.py. The great thing is that I didn't even have to change my svn repository from the other configuration, as I'd had the foresight to add them all as subfolders of /trunk.

This is my first production project using django, and I've set it up to run on Amazon's EC2 service, which has been very interesting. If anyone is curious, I've written up a howto for setting up EC2/ubuntu/django/apache2/mod_wsgi: http://drupal.atzok.com/howto_django_ec2

edit: Follow-up question:
Currently, with the exceptino of a couple of utility scripts I've grabbed from around, almost all of my code is in views.py. It's getting on to 1,000 lines now, and I don't like that one bit. What's the best way to split that up? Should I separate my main app into logical areas and split them into separate apps? If I do so, should I keep my models in the main app and reference them? Or should I just split my app into namespaced directories?

SlightlyMadman fucked around with this message at 22:18 on Oct 21, 2009

# ? Oct 21, 2009 22:08

spencer for hire: Jan 27, 2006; we just want to dance here, someone stole the stage
they call us irresponsible, write us off the page

SlightlyMadman posted:

edit: Follow-up question:
Currently, with the exceptino of a couple of utility scripts I've grabbed from around, almost all of my code is in views.py. It's getting on to 1,000 lines now, and I don't like that one bit. What's the best way to split that up? Should I separate my main app into logical areas and split them into separate apps? If I do so, should I keep my models in the main app and reference them? Or should I just split my app into namespaced directories?

I'm new to Django myself, so someone please correct me if I'm wrong, but the best idea is to split your project into multiple apps. Here's a video of a presentation by James Bennett, going over good practices to make re-usable apps.
http://www.youtube.com/watch?v=A-S0tqpPga4

Basically, a project should have many "short and sweet" apps that do one or two functions and do them well. That way, if you ever need just to re-use a portion for another project you can easily transfer the apps you want. Example: You could have a blog app that includes tagging, posting, comments, users and more -or- you could have an app for each in neatly organized packages.

# ? Oct 22, 2009 00:48

king_kilr: May 25, 2007

Speaking of reusable applications... http://djangodose.com/podcasts/callcast/episode/10/

# ? Oct 22, 2009 01:08

SlightlyMadman: Jan 14, 2005

spencer for hire posted:

Basically, a project should have many "short and sweet" apps that do one or two functions and do them well. That way, if you ever need just to re-use a portion for another project you can easily transfer the apps you want. Example: You could have a blog app that includes tagging, posting, comments, users and more -or- you could have an app for each in neatly organized packages.

Well my criteria I've been considering for whether or not to split something into a separate app is whether it's capable of running stand-alone. For instance, if a class has a foreign key reference to another, you shouldn't split them into separate apps.

The main app in my project just happens to be fairly big and interconnected, so it seems like it would be pointless to split it out, since any app I break off would be useless without the other apps.

Just curious if namespacing or pulling code out of models and views into other files is a standard thing to do, or am I hearing that if I need to do it my app is getting too complicated?

# ? Oct 22, 2009 15:50

king_kilr: May 25, 2007

By that logic almost everything in a blog post should be in an auth app because a blog belongs to a user and a tag belongs to a blog.

# ? Oct 22, 2009 21:45

SlightlyMadman: Jan 14, 2005

king_kilr posted:

By that logic almost everything in a blog post should be in an auth app because a blog belongs to a user and a tag belongs to a blog.

No, because it's not an interdependence. You can use the auth app without using a blog, but in my app there's no way any piece could function without the others.

edit: A more appropriate analogy would be a blog app with a blog listing page and a blog posting page. Sure, you could theoretically separate them out, but either one without the other would be entirely useless.

# ? Oct 22, 2009 21:50

king_kilr: May 25, 2007

SlightlyMadman posted:

No, because it's not an interdependence. You can use the auth app without using a blog, but in my app there's no way any piece could function without the others.

edit: A more appropriate analogy would be a blog app with a blog listing page and a blog posting page. Sure, you could theoretically separate them out, but either one without the other would be entirely useless.

Nowhere in your original post do you say interdependence or in any way allude to it.

# ? Oct 22, 2009 21:55

SlightlyMadman: Jan 14, 2005

king_kilr posted:

Nowhere in your original post do you say interdependence or in any way allude to it.

I did say "big and interconnected," but I apologize if my tone was offensive. My point is simply that I know everything I have belongs in one app, and am curious if there's a preferred method to split up the code within an app.

# ? Oct 23, 2009 02:54

Adbot: ADBOT LOVES YOU

# ? May 19, 2024 00:45

nbv4: Aug 21, 2002; by Duchess Gummybuns

I split it up based on functionality. I try to have each app do one thing. If that means I have to import 20 models, then so be it. For instance I have one feature of my project where the user can print out a copy of their account data into a PDF document. That functionality is one app. I have another app where it takes data from the user's account and creates a kmz file for viewing in google maps. It's it's own app too, even though it pretty much takes all it's info from just the 'flight' app.

# ? Oct 23, 2009 12:06

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Django Web Framework: The 'D' is silent dumbass

«‹›122 »