Django

A web framework (helps build web applications) that uses the Model-Template-View architectural pattern.

Basics

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 base urls.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.

• 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

Commands

(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 / Templates / Views

• 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
• 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.”
  • 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

Getting Information From Forms

• 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
• 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 a GET request can easily be bookmarked, shared, or resubmitted.”
• 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.pyfile, 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

Widgets

• 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/