Skip to main content

Starting A New Project In Django

Purpose

What follows are streamlined notes following Django's web app tutorial.

Project

Assuming that you have Python and Django installed and, if needed, are running the appropriate environment, you begin a project by navigating to the desired project directory and running the command
django-admin startproject <project name here>
 This creates a directory for your project with the basic file structure.

App

A Django app encapsulates some site function (e.g. registration). To create a Django app, run the following command in the directory where you want to implement it:
python manage.py startapp <app name here>
As of Django 2, it appears that the app is automatically registered with the setup (settings.py), saving time.

 Errata.  Above I stated that an app does not need to be "installed" in Django 2.  This is not correct.  To install an app (necessary for using app models), add
<app name>.apps.<app name>Config (e.g. Example.ExampleConfig)

to the INSTALLED_APPS list in settings.py.  Essentially, <app name>Config is a class that (I think) provides information about the app to the project as a whole.

Views

A web app is made up of controllers which draw from models to deliver views.  A controller is a Python function; Django calls the function when the user enters an url.  Django thus requires some scaffolding (designed by you, the developer) that associates urls and controllers.  This scaffolding exists in two places.
  1. A "master index" in the main project directory called urls.py.  This tells Django which base-paths to associate with which apps (e.g. to associate myapp/register with the registration app).
  2. A "sub-index" in the app folder. This allows the app to link up specific controllers with specific urls.
Remember: an app has controllers and controllers deliver content to the user.

Setting Up Views

Master-Index: The master index exists in the urls.py in the main project directory (under the directory containing manage.py). You need to import include and path from django.urls.  The include function tells Django where the sub-index (#2 above) is located, and takes an argument of the form
<app name here>.urls
The path function then associates this index with a given url.  The all-purpose form of a path call in the "master index" is
path(<regular expression defining a url>, <index to associate with the url>)
Finally, each of these "paths" is part of a list a list called urlpatterns (I have described the structure of the index from "inside-out" -- but when defining that structure you will work from "outside-in," first importing the path and include functions, then defining your list of urlpatterns, then finally associating various paths with various sub-indexes.

Sub-Index: Each app has its own sub-index.  The logic involved in defining a sub-index is very similar to that involved in defining a main-index, except that a sub-index associates urls, not with applications (of course), but with the controllers of a given application.  Thus, when defining the path for a given url, the second argument identifies a controller instead of a sub-index.  The all-purpose form is thus
path(<regular expression defining a url>, <controller to associate with the url>)
Optionally, you can add a name for that view to simplify references through the rest of the application.  Note, also, that the controller is called using Django's dot notation.  The general form is
<controller name>.<function name>
Finally, in order for Django to find the views.py file (where each controller for the app is defined) you must import it from the application directory.  This is accomplished with the following directive:
from . import views 
So again, in the normal working order, you will first import the views.py and the path function (no need for include, since we're at the app level), then define your urlpatterns, adding paths that associate specific urls with specific controllers from the views.py file.  (Conceivably, you could further modularize your controllers by creating specific view files for specific controllers, then importing and referencing each -- but don't take my word for it.)

Review

To setup a new Django project, you first run the command startproject from django-admin, passing it your project name.  This sets up the basic file structure.  You may then create apps associated with different project functionalities (e.g. registration), which by contrast are initialized from the manage.py file using the command startapp, which is passed the name of the app.  Finally, you must scaffold a main index that will tell Django which app to associate with which base url, and sub-indexes that tell each app which controller to associate with which complete url.

Comments

Post a Comment

Popular posts from this blog

Getting Geodata From Google's API

The apps I'm going to be analyzing are part of Dr. Charles Severance's MOOC on Python and Databases and work together according to the following structure (which applies both in this specific case and more generally to any application that creates and interprets a database using online data). The data source, in this case, is Google's Google Maps Geocoding API.  The "package" has two components: geoload.py  and geodump.py .  geoload.py  reads a list of locations from a file -- addresses for which we would like geographical information -- requests information about them from Google, and stores the information on a database ( geodata.db ).  geodump.py  reads and parses data from the database in JSON, then loads that into a javascript file.  The javascript is then used to create a web page on which the data is visualized as a series of points on the world-map.  Dr. Severance's course focuses on Python, so I'm only going to work my way through ...
Post a Comment
Read more

Compiling and Executing Java Files With -cp

I decided I was going to "man up" and figure out how to compile a java program with an external dependency from the command line instead of relying on an IDE-- the DOS command line, to be more specific. I ran into a few problems: 1.  The external dependency was given to me as a java file.  I experimented compiling it as a .jar, but I wasn't sure how to import a class from a .jar, so I ended up compiling it into a class. 2.  When I tried to run the file, I got an error saying that the class had been compiled with a different version of Java than my JRE.  The Internet told me to check my path variable for Java.  It sure looked like it was pointing to the latest JRE (and the same version of Java as my compiler).  I asked the Internet again and found the following command: for %I in (java.exe) do @echo %~$PATH:I I'm not exactly sure what the syntax of that magic command is (intuitively it's returning the path that executes when I run the "java" com...
Post a Comment
Read more

Quick Find / Quick Union (Connected Nodes)

Setup This week I learned about the "Quick Find" or "Quick Union" algorithm. Imagine an NxN grid of nodes, some of which are connected by lines. A connection can be interpreted as accessibility: if two nodes are connected, you can get from one to the other. Every node is accessible to itself: to get where you already are, stay there. Also, If you can get from A to B, you can go back from B to A. And if you can get from A to B and from B to C, then you can get from A to C. As a consequence, the connection between nodes divides the grid into regions of mutually accessible nodes. You can travel from any node in a given region to any other node in that region -- but not to any nodes outside that region (exercise to reader -- proof by contradiction). The problem has two parts. First, find a way to represent this grid structure and the accessibility relation; second, use your schema to efficiently calculate whether two given nodes are accessible to each other. ...
Post a Comment
Read more