we covered setting up a basic Django project. By now you should have a directory that looks like this: In our last tutorial 0to100├── CHANGELOG.rst├── .gitignore├── .git│   └── HEAD│   ...├── README.rst├── docs├── requirements│   └── base.txt├── setup.py└── tutorial├── manage.py└── tutorial├── __init__.py├── settings.py├── urls.py└── wsgi.py 4 directories, 9 files Starting your app goes over creating your first app pretty well, but they skip out on a few important concepts. Instead of explaining everything along the way the tutorial, a lot is skipped for the purposes of being concise and quick. Before we start building an app, what exactly is an app? The Django Project’s tutorial Understanding what an App is. The first thing to understand is what exactly an app is. Unlike most MVC (or MTV) frameworks, Django forces you to break your code into separate “apps.” These apps should be totally self-contained, reusable, and plug-able. This is incredibly helpful because it means you can share functionality across multiple projects. For instance suppose you have a blog app and a photo gallery app. Now a common piece of functionality you might want to add to both of those is the ability to add “tags” to photos and blog posts. Now you could write that functionality into both apps and end up having a bunch of duplicate code that does the exact same thing. Django’s preferred method is to add a new app called “tags.” This app would contain all of the data and logic concerned with adding, removing, and editing tags from other apps. This ability to be self contained also means you can share your code with others and they can also use it. For instance if you didn’t want to write your own tagging library you could just run and now you have a self contained tagging library that someone else wrote. Because of the way taggit was written it can be use with any other apps. pip install taggit How do you decide what should be an app? This is probably the single biggest question new Django developers face. How do you know when certain functionality should be split up. Due to the nature of programming there isn’t a hard rule on this. The idea I ususally follow is: “If you can’t explain what your app does in one sentence, it should be more than one app” and so far that has served me pretty well. How startapp works So enough prose and theory, let’s actually write some code! To start an app in Django, make sure you are in the first “tutorial” folder. I will refer to this as your ‘django project folder’ from here on (the one with ). This folder will be where all of your apps live. Now run: manage.py $ python manage.py startapp polls$ ls Now as you can see we now have new folder called . While it may seem like startapp does some kind of magical thing to create this app, it actually doesn’t. All that happens is a folder is created with the name provided (i.e. polls), a few files are copied in, and one config file is added (apps.py). In fact you could create your own app in the terminal or in your file explorer just by creating 1 folder and 2 files. All that is required for an app folder is the folder, an , and an . polls __init__.py apps.py What gets created? So what does actually create? Let’s take a look and breakdown every file: startapp $ tree pollspolls├── admin.py├── apps.py├── __init__.py├── migrations│   └── __init__.py├── models.py├── tests.py└── views.py First there is the file. This file is where you generally put all of your configuration regarding Djangos builtin admin. admin.py Next is this file is used in Djangos internal app registery and is mainly used to store meta data. For the most part you won’t be modifying this much. apps.py, Then we have the file. This file is actually Pythons convention for determining modules. When you try to run or Python will search all folders in the Python Path. If a folder has an __init__.py file, Python will also search inside of that folder, otherwise it is ignored. So if we want to be able to import code from our app we need __init__.py. __init__.py import library from library import x polls Now we have the folder. Migrations are how Django builds your database. We will get into this later, but you will see “migrations” added to this folder as we start working with models. migrations Then we have the this file is where you should store all of your models related to this app. Models are how Django understands your database and how you want data stored. models.py Next we have . Sometimes you will see this as a folder instead. This file/folder is for adding unit and integration tests. This is something we will cover in much greater detail later on, but basically a test is code you write to make sure your code is running how you expected. tests.py tests Finally we have . This is the file where all of our business logic is stored. We will define all of our views related to this app, both Class-Based and Function, in this file. In other frameworks, you would probably call Djangos views “Controllers”. views.py Wait, that’s not all is it? If you’ve worked with Django or other MVC frameworks before you may notice something is missing. There isn’t anywhere to store static files or templates (views in other frameworks). By default doesn’t create these, but you can by running: startapp $ mkdir static templates$ lsadmin.py  apps.py  __init__.py  migrations  models.py  static  templates  tests.py  views.py That works perfectly fine and now Django will automatically start looking for static files in and looking for templates in . polls/static polls/templates You can also add more files just for the sake of organization too! I’ll review a few other files that are relatively common: — Used to store app specific mappings of URLs to views urls.py — Commonly used to store Djangos forms library subclasses forms.py — Commonly used to store “ ” in Django. signals.py signals Commonly used by third party libraries line Django Rest Framework and TastyPie to store api information. api.py — — Used to store Queryset managers managers.py Additionally a lot of third-apps use separate files similar to to store configuration on a per app basis. api.py Registering your App So now you’ve created an app, you know what everything does, but Django still does not know about your app! To make Django aware of your app you need to edit the file. Once you have it open search for , you should see a section that looks like this: tutorial/settings.py INSTALLED_APPS INSTALLED_APPS = ['django.contrib.admin','django.contrib.auth','django.contrib.contenttypes','django.contrib.sessions','django.contrib.messages','django.contrib.staticfiles',] This is a list of all of the apps that Django will use when you start up. To make Django aware of your amazing new polls app, just add to the end of the list: 'polls', INSTALLED_APPS = ['django.contrib.admin','django.contrib.auth','django.contrib.contenttypes','django.contrib.sessions','django.contrib.messages','django.contrib.staticfiles','polls',] That’s it. You have officially created a brand new app and made it compatible with Django! It doesn’t do a whole lot yet, but we will start to fix that in the next tutorial.

BUNCH

Too Long; Didn't Read

Making security fun one episode at a time

0–100 in Django: Starting an app the right way

Too Long; Didn't Read

Companies Mentioned

Jeremy Spencer

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

0–100 in Django: Starting an app the right way

Too Long; Didn't Read

Companies Mentioned

Jeremy Spencer

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES