views:

66

answers:

4

I've noticed there's a lot of confusion about what "app" means in Django, due in no small part to the documentation only explaining this abstract concept with more abstraction. ( http://docs.djangoproject.com/en/dev/intro/tutorial01/ )

What are some concrete examples of things that should be turned into apps?

A: 

The entirety of django.contrib. See http://docs.djangoproject.com/en/dev/ref/contrib/ for an explanation of what each app does.

Basically any set of functionality that can be boiled down into a project-independent utility should become a reusable app.

sdolan
That's a nice example of some things that **are** apps, but not of things that **should be** apps. Looking at Python's standard libraries, for example, isn't very instructive in deciding how to split up your own Python projects.
blake8086
The way to look at is that the **are** apps because they **should** be apps. If you posted some details on what your project does, we could help you tell you how you may be able to split it up into separate apps.
sdolan
+1  A: 

I think of a Django "app" is a high level feature of a site. Say there is a site that offers Forums, Life Chat, FAQ, and an Image Gallery. I would create a separate Django app for each of those 4 features. Each app can have, but doesn't necessarily NEED to have, it's own Models, Views, Templates (and potentially middleware and other things) that are all closely related and serve a single high level purpose.

That's how I would explain it.

Matthew J Morrison
A: 

I am currently building a distributed application using Python/Django. Any particular server will need to reference a core set of capabilities, plus specific capabilities for its situation. Some pieces will need the full model-view-template system, others will just need to share models. One part of the application will use an in-memory database while the rest of the application uses an Enterprise-class database.

I've chosen to structure this application as a set of 'apps' that can be turned on or off by using a 'smart' settings.py and urls.py scripts. The 'core' app will only have models that are common to the entire application (but no views or templates). The 'webcore' app will add views and templates that are common across all of the apps that provide a web UI. Other apps will have their own models, plus appropriate views and templates. Some apps will only implement background services, and so won't need views or templates.

By combining multiple apps in the settings.py and urls.py scripts, I can build and test small pieces of the application, without having to deal with the complexity of the entire application. I can also distribute parts of the application to multiple servers (for scaling or to take advantage of unique resources). If I were building this application using a single 'app' I'd lose a lot of flexibility.

Craig Trader
A: 

This talk by James Bennett should answer all your questions :)

Cesar Canassa
Nope. I watched the talk, read the docs, read a bunch of blogs, Googled, and no one gives good examples like I am asking for. Thanks, though!
blake8086