In the urls.py module, we tie each view to a URL. There are many ways of doing this. I chose the simplest one, which works perfectly for the extent of this exercise, but you may want to explore this subject more deeply if you intend to work with Django. This is the core around which the whole website logic will revolve; therefore, you should try to get it down correctly. Note that the urls.py module belongs to the project folder:

# regex/urls.py
from django.contrib import admin
from django.urls import path
from django.contrib.auth import views as auth_views
from django.urls import reverse_lazy
from entries.views import HomeView, EntryListView, EntryFormView

urlpatterns = [
    path('admin/', admin.site.urls),
    path('entries/', EntryListView.as_view(), name='entries'),
    path('entries/insert',
        EntryFormView.as_view(),
        name='insert'),

    path('login/',
        auth_views.login,
        kwargs={'template_name': 'admin/login.html'},
        name='login'),
    path('logout/',
        auth_views.logout,
        kwargs={'next_page': reverse_lazy('home')},
        name='logout'),

    path('', HomeView.as_view(), name='home'),
] 

If you are familiar with version 1 of Django, you will notice some differences here, as this project is coded in version 2. As you can see, the magic comes from the path function, which has recently replaced the url function. First, we pass it a path string (also known as a route), then the view, and finally a name, which is what we will use in the reverse and reverse_lazy functions to recover the URL.

Note that, when using class-based views, we have to transform them into functions, which is what path is expecting. To do that, we call the as_view() method on them.

Note also that the first path entry, for the admin, is special. Instead of specifying a URL and a view, it specifies a URL prefix and another urls.py module (from the admin.site package). In this way, Django will complete all the URLs for the admin section by prepending 'admin/' to all the URLs specified in admin.site.urls. We could have done the same for our entries application (and we should have), but I feel it would have been a bit of overkill for this simple project.

The URL paths defined in this module are so simple that they don't require any regular expression to be defined. Should you need to use a regular expression, you can check out the re_path function, which is designed for that purpose. 

We also include login and logout functionalities, by employing views that come straight out of the django.contrib.auth package. We enrich the declaration with the necessary information (such as the next page, for the logout view, for example) and we don't need to write a single line of code to handle authentication. This is brilliant and saves us a lot of time.

Each path declaration must be done within the urlpatterns list and on this matter, it's important to consider that, when Django is trying to find a view for a URL that has been requested, the patterns are exercised in order, from top to bottom. The first one that matches is the one that will provide the view for it so, in general, you have to put specific patterns before generic ones, otherwise they will never get a chance to be caught. To show you an example that uses regular expressions in the route declaration, '^shop/categories/$' needs to come before '^shop' (notice that the '$' signals the end of the pattern, and it is not specified in the latter), otherwise it would never be called.

So, models, forms, admin, views, and URLs are all done. All that's left is to take care of the templates. I'll have to be very brief on this part because HTML can be very verbose.