-
Notifications
You must be signed in to change notification settings - Fork 2
Django
A web framework (helps build web applications) that uses the Model-Template-View architectural pattern.
Check out the documentation here: https://docs.djangoproject.com/en/4.1/
-
Note which version of Django we are using, check bottom-right corner of the screen to see if you’re on the right version of the docs.
-
For a quick tour of Django’s various functions and some tips and terminology, highly recommend reading through at least the first part of their beginner’s tutorial: https://docs.djangoproject.com/en/4.1/intro/tutorial01/
- Skim through subsequent tutorials to see if it has information on whatever it is you want to do — likely to be clear and helpful.
-
Every time you create a new app, you’ll need to also make a
urls.py
to set up URLconf and include the url pattern in the baseurls.py
file (inside the main project directory)- Also, new apps should be housed in directories on the same level as the
manage.py
file - See Django tutorial part 1 for more information on setting up a new application — what you need to know, explanations for why things are the way they are, what the heck the path and include functions do, etc.
- Also, new apps should be housed in directories on the same level as the
-
You can refer to the base project directory using the BASE_DIR variable in the
settings.py
file -
From docs: “Django apps are “pluggable”: You can use an app in multiple projects, and you can distribute apps, because they don’t have to be tied to a given Django installation.”
-
To ensure that django knows an app you’ve written is to be ‘included’, make sure to add
<app-name>.apps.<AppName>Config
— note the capitalized letters — to settings file
(all of these should be preceded by python manage.py
- runserver — runs the server; basically sets up the server and lets you see what the website looks like
- startapp — creates base directory for making an app
- collectstatic — something to do with letting Django use local assests?? [may wish to look into this
- shell — invokes the python shell, but realistically you can also just do this from inside pycharm
- makemigrations — lets you store any changes you make to your models as a migration (human-editable file on disk)
- migrate — applies changes to your database
- check — examines your project for problems without touching the database or making any migrations
- Models are database layouts with extra metadata involved (see Django tutorial 2 for extra information on this)
- Represented in code using Python classes, inheriting from django’s
models.Model
- Various class variables inherited, each represents a database field, which is itself represented (in code) by an instance of the Field class
- Represented in code using Python classes, inheriting from django’s
- Views:
- public interface, returns either an HTTPResponse obj or raises exception (404)
- “Each view is responsible for returning an
[HttpResponse](https://docs.djangoproject.com/en/4.1/ref/request-response/#django.http.HttpResponse)
object.”
- “Each view is responsible for returning an
- type of webpage
- has specific purpose
- associated with particular template
- represented by Python function / method
- Django chooses which one to use based on part of URL after domain name
- use angle brackets in setting up url patterns to indicate it should be sent as an arg to the function being called — converter:pattern_name means converter is the data type it should match and pattern_name is the name this will be referred to with
- Templates meant specifically to allow separation of page design from Python code
- in each app, need “templates” directory — Django looks in there for each of INSTALLED_APPS
- have to namespace them, so inside templates directory is ANOTHER directory named polls, and then inside that is the templates files
- public interface, returns either an HTTPResponse obj or raises exception (404)
- i have a note on the “render” function, for some reason. it takes HTTP request, template name, and optional also a dict. i think it returns a view or something.
- future resources for investigating getting information from the user via the webpage / https requests:
- tutorial [the basic beginner’s tutorial might have something, i haven’t investigated that fully]
- https://docs.djangoproject.com/en/4.1/topics/forms/ — introduction to how Django works with forms [haven’t looked at this all the way through yet; has a very nice tutorial for contact form :) ]
- https://docs.djangoproject.com/en/4.1/ref/forms/fields/ — overview of key points on the Field class, which is important for working with Form class
- https://docs.djangoproject.com/en/4.1/ref/forms/api/ — more technical detail on Django’s Form class
- https://docs.djangoproject.com/en/4.1/topics/email/ — information for sending email
- future resources for investigating getting information from the user via the webpage / https requests:
- current as of Jan 03, 2023: only Contact page uses a form, method is POST
- in HTML, inside … action attribute specifies URL to send the data to and method attribute specifies how (POST vs GET)
- “Any request that could be used to change the state of the system - for example,
a request that makes changes in the database - should use
POST
.GET
should be used only for requests that do not affect the state of the system.”- “On the other hand,
GET
is suitable for things like a web search form, because the URLs that represent aGET
request can easily be bookmarked, shared, or resubmitted.”
- “On the other hand,
- “Any request that could be used to change the state of the system - for example,
a request that makes changes in the database - should use
- in HTML, inside … action attribute specifies URL to send the data to and method attribute specifies how (POST vs GET)
- In order to send an email, use Django’s send_email function (docs here: [htps://docs.djangoproject.com/en/4.1/topics/email/](https://docs.djangoproject.com/en/4.1/topics/email/))
- minimum settings necessary to make send email (add to
settings.py
file, though do note this is wildly insecure):- EMAIL_BACKEND = ‘django.core.mail.backends.smtp.EmailBackend’
- EMAIL_HOST = ‘smtp.gmail.com’
- EMAIL_USE_TLS = True
- EMAIL_PORT = 587
- EMAIL_HOST_USER = # sender’s email-id
- EMAIL_HOST_PASSWORD = # password associated with above email-id
- also have set
DEFAULT_FROM_EMAIL
setting to be a different email, as django’s default is webmaster@localhost and gmail will sometimes automatically block emails from localhost - note that this is specifically for gmail, and that for authentication to work (so django can actually access and send emails), you need to generate an app password and paste the 16-character code in for
EMAIL_HOST_PASSWORD
(instructions for generating an app password here: https://support.google.com/accounts/answer/185833#zippy=%2Cwhy-you-may-need-an-app-password%2Cforgot-your-app-password) - actual complete tutorials for doing this:
- https://www.geeksforgeeks.org/setup-sending-email-in-django-project/ ← short, covers all the settings you need
- https://www.geekinsta.com/send-email-from-django-using-gmail-smtp/ ← mentions Mailtrap, which may be useful for testing
- https://www.sitepoint.com/django-send-email/ ← tells you a little more about what each of these settings actually mean
- minimum settings necessary to make send email (add to
- widgets in django have to do with how the html is rendered — mostly to do with front end files — while form fields have more to do with back end
- in order to have things like ‘class’, ‘id’, and ‘placeholder’ attributes associated with a given input field, you need to assign the field a widget, then assign the widget those attributes
- make sure to check what a given form field’s default widget is — you want to use and edit that type of widget and not accidentally assign the wrong type
- this page has the most information about it: https://docs.djangoproject.com/en/4.1/ref/forms/widgets/
- in order to have things like ‘class’, ‘id’, and ‘placeholder’ attributes associated with a given input field, you need to assign the field a widget, then assign the widget those attributes
For a brief overview of the MVT architectural pattern that Django uses: https://python.plainenglish.io/the-mvt-design-pattern-of-django-8fd47c61f582
- Note! You will probably see a lot of talk of templates, which are what Django uses for its frontend. It allows you to have “dynamic HTML” (regular HTML with bits that change based on database information) and I think you have to use Django’s native template language to mark it up. Sorry, I think you have to learn that now.
Using the template system in Python is a three-step process:| First: You configure an
Engine
. Second: You compile template code into aTemplate
. Third: You render the template with aContext
.
information can be sent from backend to front end in the form of a “context” (dict with variable name for the django template language mapped to some python value / variable!
Example of most correct file structure — think of apps as classes; they perform one particular function
- projectname (folder)
-
app1 (folder)
- templates (folder)
- app1 (folder)
- .html files will go in here
- app1 (folder)
- static (folder)
- app1 (folder) ← yes i KNOW, but django will have an easier time finding files if you do it like this — the documentation specifically recommends it
- images (folder) ← note that for files in this folder, you will have to do
‘images/<file name>’
when referring to them - .js, .css files go in here
- images (folder) ← note that for files in this folder, you will have to do
- app1 (folder) ← yes i KNOW, but django will have an easier time finding files if you do it like this — the documentation specifically recommends it
- templates (folder)
-
app2 (folder)
- templates (folder)
- app2 (folder)
- static (folder)
- app2 (folder)
- templates (folder)
-
projectname (folder)
- init,
settings.py
, etc. go in here
- init,
-
static (folder)
- this is for .js and .css files that will be used in multiple apps
- if you want this folder included, you will need something like the following:
STATICFILES_DIRS = [ BASE_DIR / "static", '/var/www/static/', ]
-
manage.py
(file)
-
- URL dispatcher (what is it, what does it do)
- URLconfs map URL patterns to views
- django tutorial part 3 has notes on raising exceptions and working with views — kind of important!
- the way that django does inheritance for templates (how django does “Views”)
-
managing static files!!- note that you cannot just use straight HTML (e.g. having a loop that generates the page line by line — you will not be able to have any javascript or css or images)
- you need to be VERY careful with file structure and may have to specify static file directories in order to get django to recognize what static files to ‘serve’
- setting up database: see django tutorial pt 2 for starting points
- django admin (see django tutorial pt 2)
- About the broken pipe error that pops up whenever you run the server: it seems to a Django problem we can’t do anything about? (https://bugzilla.mozilla.org/show_bug.cgi?id=1354544)