🚀 Django Day 18 — Wrapping Up Templates & Error Handling Today I wrapped up work on templates by checking my project for any remaining hardcoded HTML and converting those parts into reusable template files 🧩. I also created a custom 404.html template to handle wrong or non-existent URLs, so users see a friendly error page instead of the default debug message ⚠️. To display a custom 404 page I first experimented with render_to_string, which renders a template into an HTML string. For example, I used something like response = HttpResponseNotFound(render_to_string("404.html")) to return the rendered HTML as a 404 response. Then I learned about the Http404 exception. Instead of manually rendering and returning a 404 response, I can raise Http404("Page not found"), and Django will automatically use my 404.html template (if it exists) to show the error page. I found this approach cleaner and more idiomatic because: ✅ Less code — raising Http404 is shorter than building and returning a full response. ✅ Built-in behavior — Django’s error handling pipeline already knows how to find and render 404.html, so I don’t need to duplicate logic. ✅ Better separation — raising an exception keeps view logic focused on business rules; the rendering of error pages stays in Django’s standard flow. After switching to Http404, my error handling looks neater and follows Django best practices — and the custom 404 page now appears automatically when I test an invalid URL. It’s a small improvement, but it makes the app feel more polished. ✨ #Django #Python #WebDevelopment #LearningInPublic #100DaysOfCode #PythonJourney #lexisslearns 🚀

🚀 Django Day 12 – Working with Templates and Static Files Today, I learned how to properly structure my HTML code and connect it dynamically to Django using templates 🧩. Before now, I used to write my HTML code directly inside my main Python files, but that method isn’t ideal when building larger projects. Using templates makes the structure cleaner, reusable, and easier to manage. Templates are basically HTML files that hold your markup and can display dynamic content passed from Django views. To get started, I created a new folder inside my "challenges app" called templates, and inside it, I added a file named "challenges.html". This file will hold the HTML structure that connects to the "views.py" file (one of the inbuilt Django files I mentioned in Day 4 and Day 5). For Django to recognize my template, I had to configure it inside the inbuilt "settings.py" file by adding the app name (the one containing the template folder) to the "INSTALLED_APPS" section. This tells Django where to look for my HTML files. Next, I learned how to render these templates so they can be displayed in the browser. Rendering is simply the process of linking the backend logic with the frontend interface. There are two main functions I came across: ⚙️ render() – This is the function I used. It combines the HTML file with the data from my view and sends it straight to the browser. ⚙️ render_to_string() – This one works similarly but returns the HTML as a string instead of displaying it immediately. It’s useful for special cases like sending emails or generating HTML dynamically in code. Personally, I prefer using the "render()" function because it’s shorter, cleaner, and fits perfectly for what I’m building. 😅 Each day, I’m starting to see how Django connects all the parts together — from views and URLs to now working with templates and static files. #Django #python #DjangoJourney #Day12 #PythonDeveloper #WebDevelopment #LearningInPublic #100DaysOfCode #lexisslearns

🚀 Django Day 24 – Adding Images to the Project 🖼️ In yesterday’s video 🎥, I showed how the website looked like — it was coming together nicely, but there were no images on it yet 😅. So today, I decided to work on that and bring more life and visual appeal to the blog page 🌄. In Django, images are considered static files, which means they are implemented and attached in the same way CSS files are. For example, when linking a CSS file, I make use of the {% load static %} tag at the top of the HTML file, and then reference the file path like this: <link rel="stylesheet" href="{% static 'blog/styles.css' %}"> The same concept applies to images 🖼️ — for instance, if I want to add a blog banner or thumbnail, I can do something like this: <img src="{% static 'blog/images/blog-banner.jpg' %}" alt="Blog Banner"> This tells Django to look for the image in the static folder and display it properly on the page. Today’s focus was all about understanding how static files (especially images) are handled and how to properly link them within the templates. I also made sure the images directory was correctly structured inside the static folder and that my settings were configured to recognize them ✅. Now the blog page looks way more engaging and visually balanced 💻✨ There’s a video below 🎬 showing how the website looks now with images added 🩵 #Django #Python #WebDevelopment #CSS #Frontend #LearningInPublic #100DaysOfCode #LexissLearns 🚀

🚀 Django Day 16 — Understanding Template Inheritance Today, I explored one of the core features of Django’s template system — Template Inheritance. 💡 Template inheritance allows me to create a base structure that other pages can reuse. Instead of repeating the same HTML layout across multiple files, I can define it once and simply extend it wherever it’s needed. This makes my code cleaner, more organized, and easier to maintain. 🧩✨ To implement this, I created a new folder named “templates”, but this time it’s located inside my main project folder — not inside my app folder. Inside this main templates folder, I created a new file called base.html, which acts as the foundation for all my other pages. Then I made my existing templates — index.html and challenge.html — inherit from this base file using the {% extends %} tag. This tag tells Django that the template should use everything from the base.html file unless it overrides specific sections. 🏗️ Inside the base.html, I used the {% block %} and {% endblock %} tags to define placeholder sections that other templates can fill with their unique content. For example, I wrote something like: {% block content %} Page-specific content goes here {% endblock %} In my index.html and challenge.html, I simply added: {% extends "base.html" %} {% block content %} Page content unique to this template {% endblock %} This setup allows both templates to share the same general layout — like the navigation bar, footer, or styling — while still keeping their unique content. 🌐 I also had to make a small adjustment in the settings.py file to let Django recognize my new templates folder. I did this by adding the path of the folder under the TEMPLATES setting. Once that was done, Django immediately picked up my base structure. ⚙️ It feels amazing to see how much cleaner and scalable my project is becoming and Happy last Sunday of the Month. 💪🔥 #Django #Python #WebDevelopment #CodeJourney #LearningInPublic #TechJourney #lexisslearns 🚀💻

🚀 Django Day 11 – The Index Page Today, we focused on building the index page of our Django project — the page that displays all the months as clickable links leading to their respective challenge activity views. To achieve this, we created a new path inside the urls.py file of the challenges app, which handles the logic for our monthly challenges. In order to make the page interactive, we used some basic HTML tags such as <ul>, <li>, and <a href="..">. Here’s how they work together 👇 🧩 <ul> creates an unordered list that serves as the container for all the months. 🔹 <li> represents each month as a list item within that list. 🔗 <a href=".."> makes each month name clickable, linking it directly to that month’s challenge activity page. By combining these, we created a dynamic list of all the months, where clicking on any of them takes the user straight to its respective challenge activity view. After writing the code, we started the development server (as explained back in Day 3) before saving the file. This allowed Django to automatically preview our work and point out any issues. Once everything was set, we navigated to the browser and entered: 🌐 localhost:8000/challenges/ That URL now leads to our index page, displaying all the months neatly listed and fully clickable. This marks an exciting point in the journey — my very first working website with Django. It’s simple, but it represents the foundation of web development with Django. From here, it’s all about consistency, understanding, and steady improvement. 🎥 A short video below shows how everything looks so far. #Django #Python #WebDevelopment #LearningInPublic #CodeJourney #TechJourney #lexisslearns

🚀 Django Day 28 — Custom 404 Page & Dynamic Post Details ⚙️📄 Yesterday, I worked on setting up the index page, and today I focused on making sure each post’s page displays exactly what it’s supposed to 🧠✨. I started by updating the views.py file, where I made changes to the post_detail function. This function now handles displaying the correct post content whenever a user clicks on a specific post. Then, I implemented it in the post_details.html file to show the title, image, and content dynamically. After that, I created a custom 404 error page 🚫 — this is the page users see when they try to access a post or link that doesn’t exist. To do this, I made a new HTML file named 404.html and configured it so Django automatically renders it when a page isn’t found. This makes the site feel more polished and user-friendly 😎. Now, whenever someone enters the wrong URL, instead of a boring technical error message, they’ll see a custom-designed 404 page that fits the look and feel of the project, but it cannot be implemented now due to the fact that the website has not yet been deployed🎨💡. There’s a video below showing how everything looks now 🙌 #Django #Python #WebDevelopment #ErrorHandling #Frontend #100DaysOfCode #LearningInPublic #LexissLearns 💻🔥

The Missing Link Between Views and Templates That Changed My Django Flow At first, Django Templates looked like a riddle wrapped in curly braces. I remember the temptation: “Just return HTML from the view; it’s faster.” I almost lived off HttpResponse snippets; pasting HTML strings inside my views, until the day my view files turned into unreadable soup. That’s when I decided to crack the code behind templates: understand the logic, not just the syntax. What I found flipped the switch. Early on I used HttpResponse because it felt direct and simple: from django.http import HttpResponse def hello(request): return HttpResponse("<h1>Hello, Olawoyin</h1><p>Welcome</p>") It “works”; but it mixes presentation with logic and becomes impossible to maintain. Every tiny HTML change meant editing Python files. Reuse? Impossible. Testing? Painful. So I switched to render() to keep code clean, readable, and maintainable: from django.shortcuts import render def hello(request): return render(request, "test_app/hello.html", {"name": "Olawoyin"}) Why render() wins: • separates HTML (templates) from Python (views) • makes reuse and testing easier • supports context (variables) cleanly • keeps views focused on business logic, not markup Both patterns are valid, use what fits your app and team. And that’s where I paused my deep dive, right at the point where Django’s render() hands off to something even more powerful. In the next episode, I’ll be unpacking Function-Based and Class-Based Views; how they shape your project’s architecture and why understanding them changes the way you think about Django. Stay tuned, this next part ties everything together.

🚀 Django Day 14 — Exploring Template Tags and Dynamic Pages After diving into Django Template Language (DTL) and template filters yesterday, today I moved one step further — learning about Django Template Tags. ⚙️✨ Template tags are another powerful feature built into DTL that make Django templates truly dynamic. Unlike filters that modify data, tags control the logic and structure of what gets displayed on a page. They are written using curly-brace and percentage symbols like this — {% ... %} — which tell Django to perform specific actions within the HTML file. Some common examples I explored include: 💠 {% for %} — used to loop through lists or query sets. 💠 {% if %} — used for conditional statements, to display content only when certain conditions are met.(to learn later on) 💠 {% include %} — allows reusing smaller template parts (like a navbar or footer) across multiple pages.(to learn later on) 💠 {% block %} and {% extends %} — help in template inheritance, making it easy to build large websites with shared layouts.(to learn later on) To put this into practice, I created a new template file named index.html, which displays all the months dynamically on the index page. Instead of hardcoding each month one by one, I used the for tag to loop through the list of months — making the process cleaner, faster, and easier to maintain. 🧠💻 I had already worked with basic HTML list strings in Day 11, where I made the months appear vertically as clickable links — but this time, it’s all automated through Django logic inside the template. Seeing it come together in the browser felt like a real upgrade! 🚀 Every new feature I learn reminds me that Django isn’t just about coding — it’s about writing smarter, more efficient, and dynamic web structures. 💪 #Django #Python #WebDevelopment #CodeJourney #LearningInPublic #TechJourney #lexisslearns 💻🔥

🌟 DAY 169 - Full Stack Journey 🔁 DAY 16 - Django Revision 🎯 What I Learned Today: Today, I explored how forms work in Django and built a small Web Calculator App using Python & Django. It performs ➕ Addition, ➖ Subtraction, ✖ Multiplication, and ➗ Division — all from a single web page! 💡 Key Concepts Covered: 🟩 GET & POST Methods – How data travels between the browser and server. 🟦 CSRF Token – How Django protects forms from attacks. 🟨 request.POST – How to read input values from the user. 🟧 DTL (Django Template Language) – To display dynamic results on the same page. 🟥 JavaScript Validation – To ensure both values are entered before submitting. ⚙️ How It Works: 1️⃣ User enters two numbers in the form. 2️⃣ The data is sent to Django using the POST method. 3️⃣ Django performs the selected operation in the view function. 4️⃣ The result is sent back to the same HTML page using DTL. User (Browser)   ↓ HTML Form + CSRF Token   ↓ POST Request → Django View   ↓ Perform Calculations   ↓ Return Result → Template (DTL) 💬 What I Gained: ✨ I now understand how Django connects frontend and backend using forms. ✨ I can build interactive web pages that process and display real-time results. ✨ It was fun to see my first mini Django project working perfectly! 🙌 🔥 Quote of the Day: “Small progress every day adds up to big results.” #Day169#FullStackJourney #Django #Python #WebDevelopment #BackendDevelopment #LearningJourney #365DaysOfCode #CodingLife #SoftwareEngineer

🚀 Django Day 13 — Django Template Language Today, I dived into something really exciting — Django Template Language (DTL). I learnt that DTL allows me to combine regular HTML with special Django syntax to create dynamic web pages. Instead of writing only static HTML, I can now make my pages respond to data coming from my Django views. For example, in a normal HTML file, I might write plain text, but with DTL, I can output dynamic data using double curly brackets — {{ }} — called interpolation. 💡 This lesson showed me how Django brings HTML to life by combining standard HTML with special DTL syntax to create dynamic web pages. Instead of writing plain HTML directly inside my code, I can now use template files to output real data from my views — making my web pages more flexible and scalable. I also learnt about template filters, which help transform data before displaying it. For example: {{ name|upper }} converts text to uppercase. {{ date|date:"F j, Y" }} formats a date neatly into something like October 10, 2025. These filters make templates cleaner and more powerful — helping me format and adjust values right inside my HTML, without changing the backend logic. Honestly, this concept deepened my appreciation for Django. It’s amazing how it balances simplicity and power — making backend logic and frontend structure flow together smoothly.🚀 #Django #Python #WebDevelopment #CodeJourney #LearningInPublic #TechJourney #lexisslearns 💻🔥