Author: @nextgenkhushal
Welcome to your next step in mastering Django! If you've set up a project and successfully seen that congratulations page, you might now be wondering where to actually build your features. The answer lies in one of Django's most powerful organizing concepts: apps.
This isn't just about following a framework's conventions. Understanding Django's app architecture is fundamental to building applications that can grow from a simple prototype to a platform serving millions of users. This tutorial breaks down the essential patterns for creating robust, maintainable web applications. We'll cover how to structure your project with self-contained apps and how to keep your user interface consistent and efficient with a powerful templating engine.
A Django project is the main container for your entire web application. It handles configurations, settings, and URL routing at the highest level. However, the actual features—like a blog, a user authentication system, or a product catalog—are built inside separate apps. In professional development, almost all of your code will live inside these apps, not in the main project folder. This separation isn't arbitrary; it's the foundation for building applications that scale.
Let's start with a powerful mental model that will guide all your Django development. Think of your Django project as a house, and each app as a room within that house, each with a specific purpose. This isn't just a helpful analogy; it reflects how Django is actually architected at its core.
Imagine you're building a real house. The house itself provides the foundation, the structural framework, the utilities like plumbing and electricity. But you don't live in the foundation. You live in the rooms. Each room has a specific purpose: the kitchen for cooking, the bedroom for sleeping, the office for working. Each room is self-contained with its own furniture and function, but they all share the house's infrastructure.
Django works exactly the same way. Your project provides the foundation—it manages settings, routes incoming web traffic, and coordinates how everything works together. But the real functionality lives inside apps. Each app is a self-contained module that handles a specific feature of your website.
Let's see this with concrete examples. Imagine you're building a complete web application. You might have an auth_app that functions as your kitchen—handling all the authentication recipes like user registration, login, logout, and password management. Your posts_app serves as the living room where you display general content—managing blog posts, articles, and their comments. Finally, your ecommerce_app acts as the office, handling all the business logic for products, shopping carts, orders, and payments.
This architectural approach brings three crucial professional benefits that separate amateur projects from production-ready applications.
First, it provides separation of concerns. Each app manages its own models, views, and templates. When you need to fix a bug in your authentication system, you know exactly where to look. You won't be digging through thousands of lines of mixed code. Everything related to authentication lives in the auth_app folder, making your codebase navigable and maintainable even as it grows.
Second, it enables true reusability. A well-designed app, such as a blog app, can be dropped into another project with minimal modification. You've effectively created a reusable component that you can use across multiple projects. This isn't theoretical—Django's own contrib apps like django.contrib.admin are apps that you include in every project, and they work perfectly because they're properly encapsulated.
Third, it provides scalability for development teams. Multiple developers can work on different apps simultaneously without constantly creating merge conflicts. Your authentication specialist can work on auth_app, your content team can develop posts_app, and your commerce developer can build ecommerce_app, all at the same time, all without stepping on each other's toes.
This is why Django's tagline emphasizes building "scalable" applications. It's not just about handling more users. It's about structuring your code so that your application and your development team can grow without collapsing under their own weight.
Before we create our first app, let's understand what we're building at a conceptual level. Django apps serve as blueprints for code organization, and understanding this blueprint will help you make better decisions throughout your development journey.
When we talk about Django apps being the blueprint for code organization, we mean that each app provides a standardized structure for organizing all the pieces needed for a specific feature. Every Django app follows the same organizational pattern, which means once you understand one app, you understand how all apps work. This consistency is powerful—it means you can jump into any Django project and immediately understand its structure.
On the other side of this architectural equation sits Jinja2's templating system, which serves as the engine for UI reusability. While apps organize your Python code and business logic, Jinja2 templates organize your HTML and presentation layer. Together, these two systems—Django apps for backend organization and Jinja2 templates for frontend consistency—form the foundation of professional Django development.
Throughout this tutorial, we'll build both sides of this equation. We'll create a properly structured app that follows Django's organizational principles, and we'll implement template inheritance to keep our user interface consistent and maintainable across every page of our application.
Before we begin building, let's make sure you have everything ready. This tutorial assumes you've already completed the initial Django setup process and have a working project.
You should have an existing Django project already created using the startproject command. If you followed our previous tutorial, this would be your chai_aur_django project with its basic structure in place. Your project should have successfully run at least once, showing you Django's success page.
You'll need a terminal or command prompt open and navigated to your project's root directory. This is the folder that contains the manage.py file. All the commands we'll run need to be executed from this location, so make sure you're in the right place before proceeding.
Finally, having a code editor open with your project loaded will make everything much smoother. We recommend VS Code, but any editor will work. Having an integrated terminal within your editor is particularly helpful because it keeps your code and your command line in the same workspace.
With these prerequisites in place, you're ready to create your first Django app and start building real functionality.
The first step in adding new functionality to your Django project is creating a new app. Django provides a simple command to generate the boilerplate structure for a new app, and understanding what this command does will help you appreciate the organization Django provides.
Let's create an app called chai that will eventually display information about different types of chai tea. Open your terminal, make sure you're in the same directory as manage.py, and run the following command:
python manage.py startapp chaiYou might wonder why the command is startapp rather than something more intuitive like createapp. The terminology is intentional and reflects Django's philosophy. When you run startapp, Django is giving you a starting point—a skeleton structure that you'll build upon. It's the beginning of your app, not the complete creation of it.
Let's understand exactly what happened when you ran that command. Django created a new folder in your project named chai, and inside that folder, it generated a standard set of files that every Django app uses. This structure isn't random; it's a carefully designed organization that Django expects.
Inside your new chai folder, you'll find several important files. The views.py file is where you'll write your app's logic—the functions that handle web requests and return responses. The models.py file is where you'll define your database structures when you need to store and retrieve data. The admin.py file allows you to configure how this app appears in Django's powerful admin interface. Finally, the apps.py file contains configuration specific to this app.
There's also a __init__.py file, which is empty but crucial. Its presence tells Python that this directory should be treated as a Python package, allowing you to import code from this app elsewhere in your project.
Here's the critical point that confuses many beginners: running the startapp command only creates the files and folders. It does not yet tell your main Django project that this new app exists or should be used. The files are there, sitting in your project directory, but Django won't look at them, won't use them, and won't acknowledge them until you explicitly register the app. That's our next step.
Creating the app files was just the first half of the process. Now we need to tell our Django project that this new app exists and should be active. This happens through a critical configuration step in your project's main settings file.
This registration process is Django's way of giving you explicit control over what's active in your project. You might create several apps during development, but you can choose which ones are actually running at any given time. This becomes particularly useful when you're testing new features or temporarily disabling certain functionality.
Navigate to your main project directory—the inner folder that shares your project's name and contains the settings.py file. Open settings.py in your editor. This file is Django's control panel, and you'll return to it frequently as you build your application.
Scroll down until you find a list called INSTALLED_APPS. This list might already contain several entries that start with 'django.contrib.'—these are Django's built-in apps that provide core functionality like the admin interface, authentication, and database sessions.
Add your new app to this list. The code should look like this:
# myproject/settings.py
INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'chai', # Add your new app here
]Notice the trailing comma after 'chai'. This is a Python convention that makes it easier to add more apps later without accidentally creating syntax errors. When you add the next app, you can simply add a new line without worrying about whether the previous line has a comma.
This single line of configuration has a profound effect. You've now made your main project aware of the new app, allowing it to discover its models, discover its URL configurations, and discover its templates. Without this registration step, Django would ignore the chai folder entirely, treating it as just another directory rather than a functional part of your application.
The registration is complete. Your app now exists both structurally in your file system and conceptually in Django's awareness. We're ready to build something users can actually see.
Now we get to the exciting part: creating content that users can actually see in their browsers. This step involves two interconnected pieces—the template, which is the HTML that users see, and the view, which is the Python function that delivers that HTML to them.
Before we create our first template, we need to understand a professional practice called template namespacing. This might seem like extra work at first, but it prevents a common problem that emerges as your project grows.
Imagine you have multiple apps in your project, and two different apps both create a template named home.html. When Django searches for templates, it looks through all your apps in the order they're listed in INSTALLED_APPS. It will use the first home.html it finds, even if that's not the one you intended. This collision causes bugs that are frustrating to debug because the wrong template loads, and you can't understand why.
The solution is template namespacing, and it's remarkably simple. Instead of putting your templates directly in a templates folder, you create an additional subdirectory inside templates that matches your app's name. This extra layer ensures that each app's templates are isolated and unambiguous.
Let's implement this properly. Follow these steps precisely, as the folder structure matters.
Inside your chai app folder, create a new folder named templates. Inside that templates folder, create another folder and name it chai. Finally, inside the second chai folder, create a new HTML file named all_chai.html.
Your complete folder structure should look like this:
chai/
├── templates/
│ └── chai/
│ └── all_chai.html
├── __init__.py
├── admin.py
├── apps.py
├── models.py
├── tests.py
└── views.py
Now let's add some content to your template. Open chai/templates/chai/all_chai.html and add this HTML:
<!-- chai/templates/chai/all_chai.html -->
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>All Chai</title>
</head>
<body>
<h1>All Types of Available Chai</h1>
</body>
</html>This is a simple, complete HTML document. We're keeping it straightforward for now, but soon we'll enhance it with Django's template inheritance system.
Now we need to create the Python function that will render this template. A view in Django is simply a Python function that handles a web request and returns a response. In our case, the response will be our rendered HTML template.
Open the views.py file inside your chai app folder. You'll see it's mostly empty except for an import statement. Add the following code:
# chai/views.py
from django.shortcuts import render
def all_chai(request):
return render(request, 'chai/all_chai.html')Let's understand what each part of this code does. The first line imports Django's render function, which is a powerful utility that takes a request and a template name and produces an HTML response.
The all_chai function is our view function. Every view function must accept at least one parameter called request, which is an object containing all the information about the user's web request—things like their browser type, their IP address, any form data they submitted, and much more.
Inside the function, we call render() with two arguments. The first is the request object we received, which we're passing along. The second is the path to our template. Notice we write 'chai/all_chai.html', not 'templates/chai/all_chai.html'. Django automatically knows to look in the templates folder of each registered app, so we start from the namespace folder we created.
We now have content to display and a function that knows how to display it. The final piece is creating a URL so that users can access this view from their browsers.
URL routing in Django follows a delegation pattern that keeps your project organized as it grows. Rather than having every single URL for every single app defined in one massive file, Django allows you to delegate URL handling to individual apps. Understanding this delegation is key to building scalable Django applications.
Think of it like a postal service. When a letter arrives, the main post office looks at the city name and forwards it to the correct local office. That local office then looks at the street address and delivers it to the specific house. Django's URL routing works exactly the same way.
Let's trace the journey of a web request through your Django application. This understanding will make the URL configuration make perfect sense.
A user types https://example.com/chai/ into their browser and hits enter. Their browser sends a request to your Django server. Django receives this request and immediately looks at the URL path, which in this case is /chai/.
Django opens the main project's urls.py file and scans through the URL patterns defined there. It's looking for a pattern that matches /chai/. When it finds a pattern that says "any URL starting with chai/ should be handled by the chai app," Django knows this request belongs to your chai app.
Here's where the delegation happens. Django has found a pattern that uses the include() function, which passes control to the app. The main router says, "This request is for you, chai app. Here's what's left of the URL path. You handle it from here."
Control is transferred to the app's own urls.py file. The app's router looks at the remaining part of the URL path. In this case, after removing chai/, there's nothing left—it's an empty string. The app looks for a pattern matching an empty string and finds it should call the all_chai view function.
The view function executes, renders the template, and returns the HTML response to Django. Django sends this HTML back to the user's browser, which displays the page. The entire cycle completes in milliseconds, and Django is ready for the next request.
Now that you understand the flow, let's implement it.
First, we need to modify the main project's URL configuration to delegate requests to our app. Navigate to your main project directory and open its urls.py file. You'll need to import the include function and add a new path to the urlpatterns list.
Here's what the code should look like:
# myproject/urls.py
from django.contrib import admin
from django.urls import path, include # Note the import of include
urlpatterns = [
path('admin/', admin.site.urls),
path('chai/', include('chai.urls')), # Any request to '/chai/...' is handed off
]The key to delegating URL routing to an app is the include() function. When you write include('chai.urls'), you're telling Django to look for a urls.py file inside the chai app and use the URL patterns defined there. The 'chai/' prefix means that Django will only delegate to this app if the URL starts with /chai/.
Now we need to create the app's own URL configuration file. This is a crucial point that confuses many beginners: new apps created with startapp do not have a urls.py file by default. You must create it yourself.
This design is intentional. Not all apps are meant to be user-facing. Some apps might only provide backend models or utility functions and therefore don't require their own URL routes. Django doesn't assume what kind of app you're building, so it doesn't create a urls.py file automatically.
Inside your chai app folder, create a new file named urls.py. This will be your app's private URL router. Add the following code:
# chai/urls.py
from django.urls import path
from . import views # Import views from this app
urlpatterns = [
path('', views.all_chai, name='all_chai'),
]Let's break down what's happening here. We import path from Django's URL utilities, just like in the project's urls.py. The line from . import views imports the views module from the current app. The dot means "from this directory," so it's importing the views.py file that lives right next to this urls.py file.
The urlpatterns list contains our URL definitions. Each path() call defines a URL pattern. The first argument, an empty string '', represents the root of the path delegated to this app. Remember, the project's URLs already sent us everything starting with /chai/, so this empty string pattern matches exactly /chai/ with nothing after it.
The second argument, views.all_chai, tells Django which view function to call when this pattern matches. We're referencing the all_chai function we defined earlier in views.py.
The third argument, name='all_chai', gives this URL pattern an internal name. This is optional but highly recommended. Naming your URLs allows you to reference them elsewhere in your code and templates without hardcoding paths, making your application much more maintainable. If you later decide to change /chai/ to /tea/, you only need to update it in one place instead of hunting through your entire codebase.
The wiring is complete. Requests now flow from the user's browser, through the project's main URL router, into the app's URL router, and finally to your view function, which renders the template and sends HTML back to the user.
With all the pieces in place, it's time to verify that everything works. This is one of the most satisfying moments in development—seeing your code come to life in a browser for the first time.
Start your Django development server if it's not already running. In your terminal, make sure you're in the directory containing manage.py, and run:
python manage.py runserverYou'll see Django perform its startup checks and display a message telling you the server is running at http://127.0.0.1:8000/. The server is now actively listening for requests.
Open your web browser and navigate to http://127.0.0.1:8000/chai/. Notice the /chai/ at the end of the URL—this is the path we configured in our URLs.
If everything is configured correctly, you should see your page proudly displaying the heading "All Types of Available Chai." This simple page represents a complete journey through Django's architecture. Your request traveled from the browser, through Django's URL dispatcher, into your app's URL configuration, executed your view function, rendered your template, and returned HTML to your browser.
If you see an error instead, don't panic. Error messages in Django are remarkably helpful. The most common issues at this stage are typos in file names or forgetting to register the app in INSTALLED_APPS. Check the error message carefully—it will usually tell you exactly what went wrong and where to look.
Let's take a step back and consider what we've built. Right now, our all_chai.html page is completely self-contained. It has its own complete HTML structure with <html>, <head>, and <body> tags, and it contains all its content.
This works fine for a single page, but imagine you're building a real website with dozens or even hundreds of pages. Every single page needs the same basic structure—the same navigation bar at the top, the same footer at the bottom, the same CSS stylesheet links, the same JavaScript files, the same meta tags.
Without a templating system, you'd be forced to copy and paste these common elements into every single page. Let's visualize what this looks like with two simple pages:
Your home.html file might contain the full HTML structure with a navigation bar wrapped in a <nav> element, the page-specific content inside a <main> element showing "Home" content, and a footer wrapped in a <footer> element.
Your about.html file would need to duplicate all that same structure—the exact same navigation bar code, the exact same footer code, with only the content in the middle being different.
This duplication creates several serious problems. When you need to update your navigation bar to add a new menu item, you have to edit every single HTML file in your project. Miss one file, and you'll have inconsistent navigation across different pages. When you want to change your footer copyright year or add a new social media link, you have to hunt through every template and make the same change in each one. The process is tedious, error-prone, and fundamentally unmaintainable.
This is a violation of one of the most important principles in software development: Don't Repeat Yourself, commonly abbreviated as DRY. When you copy and paste code, you're creating multiple sources of truth. Changes need to be synchronized across all copies, and inevitably, you'll miss one. The result is bugs, inconsistencies, and maintenance nightmares.
Professional developers never accept this kind of duplication. There must be a better way to define common structure once and reuse it everywhere. That's exactly what Django's template inheritance system provides.
Django's templating system, which uses Jinja2 syntax, provides a powerful feature called template inheritance that solves the repetition problem elegantly. The concept is straightforward: you define a single base template that contains all the common page structure, and you mark certain sections as blocks that child templates can override. Other templates then extend this base template and only fill in the unique parts.
Think of it like a blueprint for a house. The blueprint defines the foundation, the walls, the roof—the structure that every house of that design will have. But the blueprint has designated spaces where different rooms can go. One house might use that space for a bedroom, another for an office. The structure is the same; only the contents of those designated spaces change.
Jinja2's template inheritance works exactly this way. You create a base template called layout.html that contains all the common structure—your navigation bar, your CSS links, your footer. Inside this base template, you define blocks using the {% block name %} syntax. These blocks are placeholders that say, "A child template can put something here."
Other templates extend the base template using {% extends 'layout.html' %} and then provide their own content for those blocks. The result is the same rendered page you'd get if you copied all the common code, but the code itself stays DRY. Change the navigation bar in layout.html, and every page that extends it automatically gets the updated navigation.
Let's see this in action with our actual code.
We're going to create a project-wide base template that all our pages can extend. This template will live in a templates folder at your project's root level, not inside any specific app. This location makes sense because this base template isn't specific to the chai app—it's meant to be used across your entire project by multiple apps.
First, we need to ensure Django knows to look for templates in a project-level templates folder. Open your settings.py file and find the TEMPLATES configuration. It's a list containing a dictionary with several settings.
Look for the 'DIRS' key inside that dictionary. This key tells Django where to look for templates at the project level, outside of individual apps. If it's empty, update it to include your project-level templates folder:
# myproject/settings.py
TEMPLATES = [
{
'BACKEND': 'django.template.backends.django.DjangoTemplates',
'DIRS': [BASE_DIR / 'templates'], # Add this line
'APP_DIRS': True,
'OPTIONS': {
# ... other options
},
},
]The expression BASE_DIR / 'templates' constructs a path to a templates folder at your project root. BASE_DIR is a variable Django sets automatically that points to your project's root directory (where manage.py lives).
Now create this templates folder at your project root, at the same level as manage.py.
Inside your new project-level templates folder, create a file named layout.html. This will be your master blueprint. Add the following code:
<!-- templates/layout.html -->
{% load static %} <!-- 1. Makes the {% static %} tag available -->
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>{% block title %}Default Title{% endblock %}</title> <!-- 2. -->
<link rel="stylesheet" href="{% static 'css/main.css' %}">
</head>
<body>
<nav>
This is our Nav Bar
</nav>
<main>
{% block content %}{% endblock %} <!-- 3. -->
</main>
<footer>
Footer
</footer>
</body>
</html>Let's understand the three critical pieces of this template.
First, the {% load static %} tag at the very top makes the {% static %} tag available for linking CSS files, JavaScript files, and images. We covered static files in a previous tutorial, and this tag is what makes that system work in templates.
Second, we define a title block: {% block title %}Default Title{% endblock %}. This creates a named block that child templates can override. If a child template provides its own title block, that content will appear here. If it doesn't, "Default Title" will be used as a fallback. This pattern of providing sensible defaults is a best practice in template inheritance.
Third, we define a content block: {% block content %}{% endblock %}. This is the primary block where child pages will inject their unique HTML content. Notice this block is empty with no default content—this makes sense because the main content should always come from the child template, never from the base.
The navigation bar and footer are written directly in the template, not inside blocks. This means they appear on every page that extends this layout, and child templates cannot override them. This is exactly what we want for truly common elements that should be consistent across all pages.
Now let's update our all_chai.html template to extend this base layout instead of being a standalone HTML document. Open chai/templates/chai/all_chai.html and replace its entire contents with:
<!-- chai/templates/chai/all_chai.html -->
{% extends 'layout.html' %}
{% block title %}All Chai For You{% endblock %}
{% block content %}
<h1>All Types of Available Chai</h1>
{% endblock %}This code is dramatically shorter and cleaner than our previous version, yet it produces a complete HTML page. Let's trace through what happens when Django renders this template.
The first line, {% extends 'layout.html' %}, must be the very first line of the file. It tells Django's template engine that this template inherits from another template. Django will load layout.html as the foundation.
Next, Django processes the {% block title %} section. When it encounters this in the child template, it replaces the corresponding block in the parent template with this content. So instead of "Default Title," the page title becomes "All Chai For You."
Then Django processes the {% block content %} section. It takes the HTML content we've defined here—our <h1> heading—and inserts it into the content block in the parent template, right between the navigation bar and the footer.
The result is a complete HTML page with navigation, our unique content, and a footer, but we only had to write the unique parts. All the common structure comes from the base template.
Let's compare what we had before with what we have now to truly appreciate what template inheritance gives us.
Before template inheritance, our all_chai.html was a complete HTML document. It had the full structure from <!DOCTYPE html> to </html>, including head tags, body tags, navigation bar code, footer code, and the actual page content. Every piece was in this one file. Any other page we created would need to duplicate all that common structure.
After implementing template inheritance, our all_chai.html is beautifully concise. It extends the layout, defines its title in a title block, and provides its unique content in a content block. That's it. Three simple blocks of code, and we get a complete, properly structured HTML page.
The rendered result in the browser is identical, but the code is vastly superior. When we need to update the navigation bar, we edit one file—layout.html. Every page that extends it immediately reflects that change. When we need to add a new CSS file or JavaScript library, we add it once to the base template, and every page gets it.
This is the essence of the DRY principle in action. We've defined our common structure once and only once, then reused it everywhere through inheritance. Our codebase is cleaner, more maintainable, and much easier to modify as our project grows.
Now that you've seen template inheritance in action, let's take a brief tour of other important Jinja2 features you'll use regularly. Django's template language is powerful and expressive, allowing you to create dynamic pages without mixing Python code directly into your HTML.
When you want to display a value that your view passes to your template, you use double curly braces. The syntax {{ variable_name }} renders the value of a variable. For example, if your view passes a variable called user.name, you can display it in your template with <h1>Hello, {{ user.name }}!</h1>.
You can also modify variables with filters using the pipe character. The syntax {{ post.title | upper }} would display the post title in all uppercase letters. Django provides many built-in filters for common transformations like capitalizing text, formatting dates, or truncating long strings.
For more complex operations like conditional logic or loops, you use tag syntax with {% %} delimiters. These tags don't produce output themselves; instead, they control what gets rendered.
The {% if user.is_authenticated %} tag allows conditional logic. You can show or hide content based on whether a condition is true. For example, you might show a login button for anonymous users but show a logout button for authenticated users.
The {% for item in item_list %} tag lets you iterate over sequences. If your view passes a list of chai types, you can loop through them and create an HTML list item for each one. This is incredibly powerful for displaying database query results or any collection of items.
We've already used the primary inheritance tags, but let's formalize their definitions.
The {% extends 'base.html' %} tag must be the first line in any template that uses inheritance. It tells the template engine that this template inherits from another.
The {% block block_name %} and {% endblock %} tags define sections that can be overridden by child templates. In the base template, they mark areas where content can be inserted. In child templates, they provide that content.
The {% url 'url_name' %} tag generates URLs based on your URL patterns' names. This is crucial for maintainability because it means you never hardcode URLs in your templates. If you change a URL pattern, all the links update automatically.
The {% load static %} tag, which we've already used, loads the static files functionality. After loading it, you can use {% static 'path/to/file' %} to generate correct URLs for your CSS, JavaScript, and image files.
These are the core Jinja2 features you'll use in almost every Django project. There are many more advanced features, but mastering these essentials will carry you through the majority of your development work.
If you're using Visual Studio Code as your editor, there's a quality-of-life improvement that will significantly speed up your HTML writing: enabling Emmet for Django template files.
Emmet is a powerful toolkit for HTML and CSS that allows you to write abbreviated syntax and expand it into full code. For example, you can type just ! and hit Tab to expand it into a complete HTML5 document structure. You can type div.container and expand it to <div class="container"></div>. These shortcuts can dramatically speed up your workflow.
By default, VS Code may not provide HTML abbreviations and expansions in files that Django identifies as django-html files, which includes your templates. This happens because VS Code sees the Jinja2 tags like {% block %} and doesn't treat the file as standard HTML. A simple setting fixes this issue.
Open VS Code's settings by pressing Ctrl + , on Windows or Linux, or Cmd + , on macOS. You can also access settings through the menu. In the settings search bar, type "Emmet: Include Languages."
Click "Add Item" under the Emmet Include Languages section. In the "Item" field, enter django-html. In the "Value" field, enter html. This pairing tells VS Code to treat django-html files like standard html files for Emmet purposes.
Now you can use Emmet's powerful shortcuts directly in your Django template files, speeding up your development workflow significantly. This small configuration change makes writing HTML templates much more efficient.
Let's step back and appreciate what you've built. You've now mastered two fundamental pillars that separate amateur Django projects from professional, production-ready applications: organizing code with Django apps and creating reusable interfaces with template inheritance.
Building a strong application isn't just about writing code that works; it's about structuring it correctly from the start. By mastering Django's app architecture, you've learned how to isolate features for clarity and reusability. Your chai app is completely self-contained with its own models, views, and templates. If you wanted to add this chai functionality to a different project tomorrow, you could copy this app folder and, with minimal configuration, have it working in the new project.
By mastering Jinja2's templating system, you've created a foundation that is not only functional but also scalable and maintainable. You define your layout once with {% block %} tags, and you reuse it everywhere with {% extends %}. When you need to update your site-wide navigation or add a new CSS framework, you change one file, and every page reflects that change immediately.
These aren't separate concepts—they work together to form Django's philosophy of building maintainable applications. Your apps organize features with separation of concerns, allowing each app to manage its own models, views, and templates. The include() function delegates URL routing, keeping your project's URL configuration clean even as you add dozens of apps. Template inheritance defines your layout once and reuses it everywhere with blocks and extends, maintaining consistency across your entire user interface.
Together, these patterns create a system that scales beautifully. Whether you're building a small personal blog or a platform serving millions of users, these same architectural principles apply. Django powers Instagram, Pinterest, and many other high-traffic sites precisely because these foundational patterns support growth without collapsing under their own weight.
Let's consolidate everything you've learned into a clear, repeatable workflow. When you need to add a new feature to any Django project, you'll follow this same pattern every time.
First, you create the app with startapp. This command generates the basic file structure with all the standard files Django apps use—views, models, admin configuration, and app configuration. It's your starting point, your skeleton that you'll build upon.
Second, you register the new app in settings.py. Add it to the INSTALLED_APPS list so your main project becomes aware of it. This single line of configuration allows Django to discover the app's models, URL configurations, and templates.
Third, you create your content by building views and templates. Write view functions in views.py that contain your business logic. Create templates following the namespacing pattern with your templates in app/templates/app/ folders. Use template inheritance to extend your base layout and fill in blocks with page-specific content.
Fourth, you wire up URLs in both the project and app level. Add a path to your project's urls.py using include() to delegate to the app. Create a urls.py in your app to define the app's specific URL patterns, mapping URL paths to view functions with named patterns for easy reference.
Finally, you leverage template inheritance to maintain consistency. Create or extend your base layout.html with common structure and defined blocks. Have your app templates extend this base and override only the blocks they need to customize, keeping your code DRY and maintainable.
This workflow is the foundation of Django development. Whether you're adding a blog feature, building an e-commerce system, or creating a user dashboard, you follow these same steps. The structure remains consistent, which means once you've mastered it, you can build complex applications with confidence.
You've now built a complete Django app with properly organized code and reusable templates. This foundation prepares you for the exciting features that make Django truly powerful for building dynamic web applications.
Your next steps should focus on passing dynamic data from your views to your templates. Right now, your templates display static content. Soon, you'll learn how to query databases, process that data in your views, and pass it to templates where you can loop through it, format it, and display it dynamically to users.
You'll explore more complex URL patterns with parameters, allowing URLs like /chai/masala/ or /chai/1/ where parts of the URL capture information that your views can use. This enables features like viewing individual items, filtering results, or creating user-specific pages.
You'll define database models in models.py, create relationships between different types of data, and use Django's powerful ORM to query databases without writing SQL. This is where Django really shines, making database operations feel natural in Python.
You'll build forms that accept user input, validate that input for security and correctness, and process submissions to create or update data. Django's form system handles much of the complexity automatically, keeping your code clean and your application secure.
Every one of these advanced topics builds directly on the foundation you've created today. You understand how apps organize your code, how views handle requests, how templates display content, and how URLs route everything together. These concepts underpin everything else you'll learn in Django.
You're well on your way to building professional, scalable web applications. Keep building, stay curious, and remember that every expert developer started exactly where you are now—with a simple app displaying a simple page. The difference is they kept going.
Happy coding Guys!