Join us and get access to hundreds of tutorials and a community of expert Pythonistas.

Unlock This Lesson

This lesson is for members only. Join us and get access to hundreds of tutorials and a community of expert Pythonistas.

Unlock This Lesson

Hint: You can adjust the default video playback speed in your account settings.
Sorry! Looks like there’s an issue with video playback 🙁 This might be due to a temporary outage or because of a configuration issue with your browser. Please see our video player troubleshooting guide to resolve the issue.

Build Views

In this lesson, you’re going to create your views and have a visit with your good friend, the AttributeError! According to this error message, the module project.views has no attribute called all_projects, so head over to views.py to create this view:

# Create your views here.
def all_projects(request):
    return render(request, 'all_projects.html')

Now, you’re getting a new error message, TemplateDoesNotExist, because you haven’t yet created this template, so Django doesn’t know what to render.

Comments & Discussion

reblark on Feb. 25, 2020

Your top level structure is Project>portfolio,projects, yes? In the views directory you import Poject from projects.models, yes?

If my structure is Gulls>pix,pixie, shouldn’t I (in “views”) import Gulls from pixie.models? forsta?

reblark on Feb. 26, 2020

It’s a tricky thing to try to copy your code but to change the key names. But, I am doing it and I think it helps in providing a deeper understanding of what is happening. Here is where I got confused. In models when you create the data base, you used the name “Project” by simply capitalizing project. My corresponding directory names were pix and pixie basically for projects and project. When I did this code to create the database, I failed to simply use “Pix”. It took time to figure that out but I did and everything works. I had to really search for this resolution and it was worth the effort. Naming is a crucial aspect of computer science and of life. Ursula Le Guins “EarthSea” trilogy was all about naming.

Martin Breuss RP Team on March 1, 2020

Congrats for figuring it out. 🙌

Did I understand correctly that you initially hadn’t capitalized the model name?

Just FYI: the model names don’t need to be a capitalized version of the Django project name. It just made sense in the projects example, since the objects we are handling in the project app are, well, Projects. :)

When you build larger Django applications you will frequently have more than one model per app, and they can be all sorts of things.

As a naming convention that you can keep in mind: the model names should always be singular. Think of it in a way that the model code will be used many times to create single instances of that class.

reblark on March 10, 2020

In the bit about using the print command as a debugging tool, when I refreshed the page, the results in the terminal window had two lines <QuerySet [<Project: Project object (1)>]>

It seems like Python must have printed the code line: projects = Project.objects.all() just prior to the print statement. Yes?

Martin Breuss RP Team on March 11, 2020

Sounds to me like you might be using print() on the queryset somewhere in your views.py file.

That would explain why it prints out to your console when you make a request on your browser (i.e. refresh the page).

R morel on May 4, 2020

def all_projects(requests): return render(requests, ‘projects/all_projects.html’)

Scretch on June 14, 2020

I really like your approach of building by errors. I am definitely one to cringe when that happens but you make a good argument of learning from these messages. I imagine dark times when devs didn’t have that in the early days and had to find the errors manually. Oof....

Martin Breuss RP Team on June 15, 2020

👆👆👆👆👆👆👆 ❗️❗️❗️❗️❗️ 👆👆👆👆👆👆👆

Totally, good point! So thanks to all the previous-time-devs for the work on making nice error messages for us! 🤓

Become a Member to join the conversation.