Skip to content
Rachel Xie edited this page Apr 28, 2023 · 6 revisions

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

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/

Supplemental

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 a Template. Third: You render the template with a Context.

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
      • 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
    • app2 (folder)

      • templates (folder)
        • app2 (folder)
      • static (folder)
        • app2 (folder)
    • projectname (folder)

      • init, settings.py , etc. go in here
    • 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)

Possible Future Avenues of Investigation

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