Part VIII - Showing the data we created on the frontend
Updated:
Explore techniques for displaying dynamically created data on the frontend, enhancing user experience with real-time updates and interactive interfaces.
The Django ORM gives a convenient way to access the database. It stands for Object Relational Mapper. In other words, it's an easier way to get data from the database. Instead of making SQL queries, it maps the attributes of objects to their respective tables. By mapping the data to the individual table using ORM, we're writing SQL queries, but we're not.
Take note that I tweaked the UI a little to make our frontend prettier.
On our homepage, we are showing 4 lists of blogs we created in the python shell. To map it using the Django ORM, we'll create a for loop that grabs the context_object_name we specified in the views.py of our BlogListView. In fact, use each of the context_object_name we specified in each of the views that we created to grab our database's data. Isn't it easy?
Notice the nested for loop for the categories? We use a for loop to loop through the data we created. Talk about how Django utilizes the DRY principle, can you?
On the post detail page, since we only are looping through each post's categories, we can still call the ORM data even if we won't use a for loop.
We're calling the categories in the a tag of the category for loop to loop through it to show all the available categories that we specified in a specific post. Then we call category.slug to help us get the right url for the post we asked for.
On our pages/category_list.html, we specify in our h1 tag the title of the category we query. We did it by mapping through {{ category.title }}. Then, we use a for loop to filter the posts the current category we asked for using the blog_category function based view.
The projects page goes the same as the other pages, so you should be able to at least have a basic understanding already of how to query the ORM from the HTML templates.
Our contact page only uses 5 lines of code to make it function since Cookiecutter-Django includes an alert on the pages/base.html template:
{% if messages %}
{% for message in messages %}
<div class="alert {% if message.tags %}alert-{{ message.tags }}{% endif %}">{{ message }}<button type="button" class="close" data-dismiss="alert" aria-label="Close"><span aria-hidden="true">×</span></button></div>
{% endfor %}
{% endif %}
And as we specified on our ContactFormView that we want the alert to be shown once the form has been submitted, it uses the alert on the base.html template since we extended the contact.html template from the base.html.
We can move the alert on the base.html too. Do it if you want to. I won't since I would be needing the alert for new features on this blog.
One last important thing on the form is the {% csrf_token %} template tag. It's the simplest way Django provides to protect us from Cross-Site Request Forgery.
According to Django's documentation, This type of attack occurs when a malicious website contains a link, a form button, or some JavaScript that is intended to perform some action on your website, using the credentials of a logged-in user who visits the malicious site in their browser. We also won't be able to deploy our project to Heroku once if we don't include that once we run a command that I'll show in a while.