Repo to accompany Djangocon 2019 talk, Generic View? What is that and why would I use it?
Basically this repo has a sample django project. The website it spins up is just a basic todo site. Honestly the UI is not great, and the functionality is...lacking to say the least. Really the purpose of this is to show examples of using class-based views (CBVs), and specifically taking advantages of the generic CBVs.
One of the features of this project is that there are CBVs set up to run the entire project and there are function-based views (FBVs) that contain similar (though not exactly the same) functionality. This makes it so that you can see side-by-side (well, top-by-bottom?) examples of both and how you might use generic CBVs to replace some of your FBVs.
All the commands below assume you have your terminal open and are in the project's root directory.
There's a Dockerfile and a docker-compose file set up so you can run this site using docker fairly easily. The docker-compose file sets up a postgres container and the settings for this project are set up to point at it.
- Run
docker-compose up -d db
- Run
docker-compose run --rm django python manage.py migrate
- Run
docker-compose up django
There are a few different options to how you can run it after you've already set it up.
- Spin up whole project
docker-compose up
- Run db first and then django server separately.
The advantage to this is that you can spin up the server, or jump into the container and not have to think about the
db since it'll just be running in the background.
docker-compose up -d db
- Just launch server
docker-compose up django
- Jump into container
docker-compose run --rm --service-ports django bash
- The service ports bit just makes it so you can run
python manage.py runserver
from within the container and have it work properly. If you only plan to runmanage.py
commands and do other things on the command line, then you can leave it off.
- The service ports bit just makes it so you can run
- Run manage.py command
docker-compose run --rm django python manage.py migrate
- Here you can replace
migrate
with any command you need to run.
- Here you can replace
- Just launch server
You don't have to use docker, but if you don't, you'll need to edit the settings to point at whatever db you plan to use. Simplest would probably be to just use SQLite, like the default settings normally have.
- Edit
gcbv_demo/settings.py
, look for theDATABASES
setting and edit it to whatever you want. You can see the django docs for more info: https://docs.djangoproject.com/en/2.2/ref/settings/#databases - Set up your virtual environment. For more info see: https://tutorial.djangogirls.org/en/django_installation/#virtual-environment
- Activate the venv (see link above for more info).
- Run
pip install -r requirements
- Run
python manage.py migrate
- Run
python manage.py runserver
- Activate your venv.
- Run
python manage.py runserver
The code has been set up to swap between the CBVs and the FBVs. The settings.py
file has this:
# Use this to trigger using the different view types
VIEW_TYPES = os.environ.get('DJANGO_VIEW_TYPES', 'CBV')
What it means is that you can set an environment variable, DJANGO_VIEW_TYPES
to trigger between CBVs and FBVs. The
code is set up to default to CBV
, and if that env var has any other value, it will use FBVs. This is an example of how
the main home page is set up (cut out irrelevant lines):
from common.views import HomeView, home_view
if settings.VIEW_TYPES == 'CBV':
urlpatterns = [
path('', HomeView.as_view(), name='home'),
]
else:
urlpatterns = [
path('', home_view, name='home'),
]
An example of running with FBVs would be:
DJANGO_VIEW_TYPES=FBV docker-compose up
...I...well I didn't write tests for this code... Terrible, I know. Like I pointed out in the beginning of this README, this repo was more about showing how generic CBVs can be used and comparing them to FBVs. Which, yes, would probably be very easy to drive home if I set up tests that run on both and work for both, but I just didn't have enough time. Maybe I'll come back and write them at some point. (We all know that's not happening...)
There's a bit of functionality set up using DRF and Vue. Neither are really fully set up the best way, I just implemented them in a very simple way to get that bit of functionality working, but they are also not the point of this repo, and should not really be used as reference.