The Internet of Things (IoT) is revolutionizing how we interact with the physical world, enabling everyday objects to connect and communicate through the internet. Combining Arduino, a popular microcontroller platform, with Django, a robust Python web framework, opens up exciting possibilities for IoT projects. This blog post will guide you through the process of integrating Arduino with Django, allowing you to control and monitor your Arduino projects via a web interface.

Why Combine Arduino with Django?

• Remote Control and Monitoring: Control your Arduino projects from anywhere in the world using a web browser.

• Data Logging and Visualization: Store and visualize sensor data collected by your Arduino in a Django-powered web app.

• Enhanced Interactivity: Create interactive web interfaces to make your projects more user-friendly.

Getting Started ...

READ HERE at medium

Head to the official documentation for multiple databases support here .

Learn Python & Django at django-tutorial.dev

Understanding Multiple Databases in Django

Django's default behavior is to work with a single database. However, it also provides built-in support for managing multiple databases seamlessly. Each database connection is represented by a Django DATABASES setting in the project's settings file. These settings define various parameters such as the database engine, name, user, password, host, and port.

Configuring Multiple Databases

To configure multiple databases in Django, start by defining each database in the DATABASES setting. For example:

 DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'my_database',
        'USER': 'my_user',
        'PASSWORD': 'my_password',
        'HOST': 'localhost',
        'PORT': '3306',
    },
    'other_db': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': BASE_DIR / 'other_db.sqlite3',
    },
}

In this example, there are two database configurations: 'default' and 'other_db'. The 'default' database is MySQL, while 'other_db' uses SQLite. You can add as many database configurations as needed.

Migrating in individual databases

The migrate management command operates on one database at a time. By default, it operates on the default database, but by providing the --database option, you can tell it to synchronize a different database. So, to synchronize all models onto all databases in the first example above, you would need to call:

py manage.py migrate
py manage.py migrate --database=default

If you don’t want every application to be synchronized onto a particular database, you can define a database router that implements a policy constraining the availability of particular models.

If, as in the second example above, you’ve left the default database empty, you must provide a database name each time you run migrate. Omitting the database name would raise an error. For the second example:

py manage.py migrate --database=defaults
py manage.py migrate --database=other_db

Using other management commands

Most other django-admin commands that interact with the database operate in the same way as migrate – they only ever operate on one database at a time, using
--database to control the database used.

An exception to this rule is the makemigrations command. It validates the migration history in the databases to catch problems with the existing migration files (which could be caused by editing them) before creating new migrations. By default, it checks only the default database, but it consults the allow_migrate() method of routers if any are installed.

Database Routing

Once the databases are configured, Django needs to know which database to use for each query. This is where database routing comes into play. Django allows you to define custom database routers to control which database to use for specific models or operations.

class MyAppRouter:
    def db_for_read(self, model, **hints):
        if model._meta.app_label == 'my_app':
            return 'other_db'
        return None

    def db_for_write(self, model, **hints):
        if model._meta.app_label == 'my_app':
            return 'other_db'
        return None

In this example, MyAppRouter routes read and write operations for models in the 'my_app' app to the 'other_db' database.

Database Routers

A database Router is a class that provides up to four methods:

db_for_read(model, **hints)

Suggest the database that should be used for read operations for objects of type model. If a database operation is able to provide any additional information that might assist in selecting a database, it will be provided in the hints dictionary. Details on valid hints are provided below.
Returns None if there is no suggestion.

db_for_write(model, **hints)

Suggest the database that should be used for writes of objects of type Model. If a database operation is able to provide any additional information that might assist in selecting a database, it will be provided in the hints dictionary. Details on valid hints are provided below.
Returns None if there is no suggestion.

allow_relation(obj1, obj2, **hints)

Return True if a relation between obj1 and obj2 should be allowed, False if the relation should be prevented, or None if the router has no opinion. This is purely a validation operation, used by foreign key and many to many operations to determine if a relation should be allowed between two objects.
If no router has an opinion (i.e. all routers return None), only relations within the same database are allowed.

allow_migrate(db, app_label, model_name=None, **hints)

Determine if the migration operation is allowed to run on the database with alias db. Return True if the operation should run, False if it shouldn’t run, or None if the router has no opinion. The app_label positional argument is the label of the application being migrated.

A router doesn’t have to provide all these methods – it may omit one or more of them. If one of the methods is omitted, Django will skip that router when performing the relevant check.

Hints

The hints received by the database router can be used to decide which database should receive a given request.

At present, the only hint that will be provided is instance, an object instance that is related to the read or write operation that is underway. This might be the instance that is being saved, or it might be an instance that is being added in a many-to-many relation. In some cases, no instance hint will be provided at all. The router checks for the existence of an instance hint, and determine if that hint should be used to alter routing behavior.

Using Multiple Databases in Views and Models

Once routing is configured, you can use multiple databases in your views and models. For example, to read from or write to a specific database, you can use Django's using method:

from my_app.models import MyModel

# Read from 'other_db'
objs = MyModel.objects.using('other_db').all()

# Write to 'other_db'
obj = MyModel(field1=value1, field2=value2)
obj.save(using='other_db')

Considerations and Best Practices

When working with multiple databases in Django, there are several considerations and best practices to keep in mind:

1. Consistency: Ensure data consistency across databases by carefully designing your database schema and transaction management.

2. Performance: Monitor and optimize database performance, especially when dealing with multiple databases.

3. Security: Secure database connections and credentials to prevent unauthorized access.

4. Testing: Test your application thoroughly, especially when using multiple databases, to ensure correct behavior in various scenarios.

5. Documentation: Document your database configurations, routing logic, and any customizations for future reference.

Conclusion

Handling multiple databases in Django opens up a world of possibilities for building scalable and efficient web applications. By understanding how to configure multiple databases, implement database routing, and use them in views and models, you can take full advantage of Django's powerful features while effectively managing your data.

(DON'T FORGET TO PULL THIS UP WHEN MEETING A HTML DEVELOPER)

Learn Python & Django at django-tutorial.dev

Difference.py :

Average HTML Fan:

Average Django Enjoyer:

Conclusion:

Sponsor this Blog to fund the Django side in this war between HTML and Django.
Mail me to update the blog with new metrics and stuff.

Learn Python & Django at django-tutorial.dev

Understanding CORS:

CORS is a security feature implemented by web browsers that restricts cross-origin HTTP requests initiated from scripts running on a web page. It is designed to prevent malicious websites from accessing resources on a different origin, thus mitigating various types of attacks such as Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF).

In Django, CORS is managed through middleware, which intercepts incoming HTTP requests and enforces CORS policies based on specified configurations.

Importance of CORS in Django API Security:

Django, being a powerful web framework for building APIs, needs to enforce strict CORS policies to prevent unauthorized access and protect sensitive data. Without proper CORS handling, your API could be vulnerable to attacks like unauthorized data retrieval or manipulation, potentially compromising the integrity and confidentiality of your application.

Practical Strategies to Handle CORS in Django:

1. Install Django CORS Middleware: Start by installing the django-cors-headers package using pip:

    pip install django-cors-headers
   

2. Configure CORS Settings: Update your Django project's settings to include CORS middleware and specify allowed origins, methods, and headers. Here's an example configuration:

    # settings.py
   
    INSTALLED_APPS = [
        ...
        'corsheaders',
        ...
    ]
   
    MIDDLEWARE = [
        ...
        'corsheaders.middleware.CorsMiddleware',
        ...
    ]
   
    CORS_ALLOWED_ORIGINS = [
        'http://localhost:3000',  # Example: Allow requests from this origin
    ]
   
    CORS_ALLOW_METHODS = [
        'GET',
        'POST',
        'PUT',
        'PATCH',
        'DELETE',
        'OPTIONS',
    ]
   
    CORS_ALLOW_HEADERS = [
        'Accept',
        'Content-Type',
        'Authorization',
    ]
   

3. Handle Preflight Requests: Preflight requests are OPTIONS requests sent by the browser to determine if the actual request is safe to send. Ensure your Django application responds appropriately to these requests by allowing them to pass through without authentication or authorization checks.

4. Test and Debug: Thoroughly test your API endpoints with different client applications and verify that CORS policies are correctly enforced. Use browser developer tools to inspect HTTP headers and responses, ensuring that CORS headers are present and accurately reflect your configured settings.

5. Implement Additional Security Measures: While CORS is essential for securing your Django API, it's just one piece of the puzzle. Implement other security measures such as authentication, authorization, input validation, and rate limiting to fortify your application against a wide range of attacks.

Conclusion:

Handling CORS in Django API security requires careful configuration and adherence to best practices to protect against potential vulnerabilities. By understanding the fundamentals of CORS, configuring middleware, and implementing robust security measures, you can ensure that your Django applications remain resilient and secure in today's dynamic web landscape. Remember to stay informed about emerging threats and updates in web security to continuously improve the security posture of your Django APIs.

Learn Python & Django at django-tutorial.dev

Understanding Django Signals

At its core, Django Signals provide a means for components within a Django application to communicate with each other in a decoupled manner. Inspired by the Observer design pattern, signals enable certain senders to notify a set of receivers when a particular action or event occurs.

Anatomy of Django Signals

Django Signals rely on the signal module, which allows developers to define custom signals and connect them to specific functions or methods. Let's break down the key components:

1. Signal Definition: Developers can define custom signals using the django.dispatch.Signal class. These signals serve as a communication mechanism, signaling when a particular event occurs. There are several Built-in signals in Django. Read about them here.

2. Signal Sender: When a specific action or event occurs within the application, the sender triggers the corresponding signal by calling the send() method. The sender can include additional data as arguments when sending the signal.

3. Signal Receiver: Receivers are functions or methods that are registered to respond to a particular signal. Developers can connect multiple receivers to a signal, enabling modular and extensible application behavior.

Practical Applications of Django Signals

Now that we understand the basics, let's explore some real-world scenarios where Django Signals can be invaluable:

1. Pre-Save and Post-Save Hooks: Utilize signals such as pre_save and post_save to perform actions before or after saving an object to the database. For example, you can automatically update related records, send notifications, or trigger additional processes based on changes to certain models.

2. User Authentication and Authorization: Implement custom signals to integrate with Django's authentication system. For instance, you can execute custom logic when a user is created, updated, or deleted, enhancing security and access control within your application.

3. Cache Invalidation: Maintain data consistency by employing signals to invalidate cache entries when relevant data is modified. This ensures that cached data remains synchronized with the underlying database, preventing stale or outdated information from being served to users.

Best Practices and Considerations

While Django Signals offer immense flexibility and functionality, it's essential to adhere to best practices to avoid common pitfalls:

• Keep Signals Simple: Resist the temptation to overcomplicate your signal handling logic. Aim for simplicity and clarity to maintain code readability and ease of maintenance.

• Avoid Tight Coupling: Strive to keep your application components loosely coupled by utilizing signals judiciously. Over-reliance on signals can lead to spaghetti code and make your application harder to understand and maintain.

• Unit Testing: Test your signal handlers thoroughly to ensure they behave as expected under various scenarios. Mocking signals and receivers can facilitate isolated testing of individual components.

Real World Application : Simplified Communication

Django Signals enable components within an application to interact without tight coupling. Key components include signal definition, sender, and receiver.

• Signal Definition: Custom signals are defined using django.dispatch.Signal, serving as communication channels for specific events.

• Signal Sender: Sends signals using the send() method when relevant events occur, including optional data arguments.

• Signal Receiver: Functions or methods connected to signals respond to specific events, allowing modular and extensible behavior.

Demo App: Notifications with Django Signals

Let's create a demo app illustrating Django Signals in action. We'll build a simple notification system where users receive a welcome message upon registration.

1. Signal Definition: Define a custom signal user_registered.

2. Signal Sender: Trigger user_registered signal upon user registration, sending user data as arguments.

3. Signal Receiver: Connect a receiver to user_registered signal to send a welcome message to the user.

Code Demo:

# signals.py
from django.dispatch import Signal

user_registered = Signal(providing_args=["user"])

# receivers.py
from django.dispatch import receiver
from .signals import user_registered

@receiver(user_registered)
def send_welcome_message(sender, **kwargs):
    user = kwargs['user']
    # Send welcome message logic here
    send_user_mail(user.email,user.username,message = "Welcome to Silk Road")

send_user_mail will be a explicitly defined function that sends mail to the user with an activation link, welcome message or anything in between. Read About how to send mail from your django app here:

# models.py
from django.db import models
from .signals import user_registered

class User(models.Model):
    username = models.CharField(max_length=100)
    email = models.EmailField()

def create_user_profile(sender, instance, created, **kwargs):
    if created:
        user_registered.send(sender=User, user=instance)

models.signals.post_save.connect(create_user_profile, sender=User)

Conclusion

Django Signals offer a concise and powerful mechanism for inter-component communication in Django applications. By understanding and harnessing their potential, developers can enhance modularity, extensibility, and maintainability. Explore Django Signals further to streamline your application's communication and unlock new possibilities. Happy coding!

Learn Python & Django at django-tutorial.dev

1. Model Signals: One of the most frequently used types of signals in Django is related to models. These signals are emitted by the Django ORM before or after certain model-related operations. For instance, the pre_save and post_save signals are sent before and after saving a model instance, respectively. Similarly, signals like pre_delete and post_delete are dispatched before and after deleting a model instance.

By connecting receiver functions to these signals, developers can perform additional tasks or execute custom logic when specific model-related events occur. For example, you might want to update related records in the database after a certain model instance is saved, or trigger notifications when a model instance is deleted.

• pre_save: Sent just before a model's save() method is called.

• post_save: Sent just after a model's save() method is called.

• pre_delete: Sent just before a model's delete() method is called.

• post_delete: Sent just after a model's delete() method is called.

• m2m_changed: Sent when a many-to-many relation is modified.

2. Authentication Signals: Django's authentication system also emits signals during user authentication-related events. Signals such as user_logged_in and user_logged_out are sent when users successfully log in or log out of the system. These signals are invaluable for implementing additional functionality, such as recording login/logout timestamps, updating user activity logs, or sending email notifications upon user login.

• user_logged_in: Sent when a user logs in.

• user_logged_out: Sent when a user logs out.

• user_login_failed: Sent when a login attempt fails.

3. Request/Response Signals: Django provides signals that allow you to hook into the request/response cycle of your web application. Signals like request_started and request_finished are dispatched when HTTP requests begin and end processing, respectively. These signals can be useful for tasks such as logging request metadata, capturing performance metrics, or implementing custom request/response middleware.

• request_started: Sent when an HTTP request begins processing.

• request_finished: Sent when an HTTP request finishes processing.

• got_request_exception: Sent when an exception occurs while processing an HTTP request.

4. Management Signals: Additionally, Django emits signals during the execution of management commands, which are used for administrative tasks like database migrations, collecting static files, and running tests. Signals such as pre_migrate and post_migrate are sent before and after database migrations are applied, allowing developers to perform setup or cleanup tasks as needed.

• pre_migrate: Sent before a migration is applied.

• post_migrate: Sent after a migration is applied.

• setting_changed: Sent when a Django setting is changed.

5. Other Signals: These are miscellaneous Signals that dont fit on above 4 categories, There is no further difference between them.

• class_prepared: Sent when a model class has been prepared.

• template_rendered: Sent when a template is rendered.

• setting_changed: Sent when a Django setting is changed.

• connection_created: Sent when a database connection is created.

Conclusion:

In conclusion, built-in signals in Django provide a flexible and powerful mechanism for extending and customizing the behavior of your web applications. By leveraging signals, developers can decouple different parts of their codebase, promote reusability, and maintain clean, modular architecture. Whether you're working with models, authentication, request handling, or management commands, Django's signals offer a robust toolkit for implementing advanced functionality and responding to various events within your application.

In the dynamic landscape of web development, staying abreast of the latest technologies is crucial. One such powerful combination is the integration of HTMX with Django, a blend that leverages modern websockets for enhanced real-time functionality. In this article, we'll delve into the world of HTMX and how it seamlessly integrates with Django to bring a new level of interactivity to your web applications.

Learn Python , HTMX & Django at django-tutorial.dev

Understanding HTMX:

HTMX, pronounced "hypertext marks," is a lightweight JavaScript library that facilitates seamless communication between the server and the client. Unlike traditional approaches, HTMX enables developers to update specific parts of a web page dynamically, without the need for a full-page reload. It achieves this by using AJAX requests, making it a powerful tool for creating responsive and interactive user interfaces.

Key Features of HTMX: Before we explore the integration of HTMX with Django, let's highlight some key features that make HTMX a valuable addition to your toolkit:

1. Declarative Syntax: HTMX employs a declarative syntax, allowing developers to define dynamic behavior directly in the HTML markup using data attributes. This simplifies the code and enhances readability, promoting a more intuitive development process.

2. AJAX Requests Simplified: By abstracting away the complexities of AJAX requests, HTMX streamlines the process of fetching and updating data from the server. This leads to cleaner code and a more efficient development workflow.

3. Compatibility with Django: HTMX aligns seamlessly with Django, making it an excellent choice for developers working within the Django ecosystem. Its compatibility extends to various Python frameworks, ensuring flexibility and ease of integration.

Integrating HTMX with Django:

Now, let's explore the steps to integrate HTMX with Django, specifically focusing on leveraging modern web sockets for real-time communication.

1. Installing HTMX: Begin by installing HTMX in your Django project. You can use package managers like pip to install the necessary dependencies. Ensure that HTMX is included in your project's static files. You can also use CDN for HTMX like this:

    <script src="https://cdnjs.cloudflare.com/ajax/libs/htmx/1.9.10/htmx.min.js" ></script>
   

2. Adding HTMX to Templates: Integrate HTMX into your Django templates by including the necessary script tags. HTMX utilizes data attributes to define behavior, so make sure to annotate the HTML elements that you want to enhance with dynamic functionality.

3. Setting Up Django Views: Update your Django views to handle the HTMX requests. This involves defining view functions that respond to specific HTMX-triggered actions. Use Django's robust capabilities to process data and return the appropriate response.

4. Incorporating Websockets: To harness the power of modern websockets, consider integrating Django Channels into your project. Django Channels extends Django to handle WebSockets, enabling bidirectional communication between the server and the client.

5. Real-Time Updates: With HTMX and Django Channels in place, you can achieve real-time updates on your web pages. For example, implement a chat application where messages are sent and received in real-time, providing a seamless and interactive user experience.

Benefits of the Integration: The integration of HTMX with Django, coupled with modern Servers, offers several benefits to developers and end-users alike:

1. Enhanced User Experience: Real-time updates create a more engaging and interactive user experience. Whether it's live notifications or dynamic content updates, users will appreciate the responsiveness of the application.

2. Reduced Server Load: By updating only the necessary parts of a page, HTMX reduces the server load compared to traditional full-page reloads. This optimization leads to a more efficient use of server resources.

3. Simplified Development: The declarative syntax of HTMX and the compatibility with Django streamline the development process. Developers can focus on building features without getting bogged down by complex AJAX implementations.

4. Scalability: Modern websockets, facilitated by Django Channels, pave the way for scalable and real-time applications. Whether you're building a collaborative editing tool or a live dashboard, the integration sets the stage for future scalability.

Here is a code snippet that demonstrates a simple implementation of HTMX with Django and real-time updates without using websockets. For the sake of brevity, we'll create a basic example of a real-time counter.

<!-- Django Template with HTMX Integration -->
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>HTMX and Django Real-Time Counter</title>
    <!-- Include HTMX library -->
    <script src="{% static 'htmx.min.js' %}" defer></script>
</head>
<body>

<!-- Counter Display -->
<h1 id="counter" hx-get="{% url 'get_counter' %}">{% block counter %}{% endblock %}</h1>

<!-- Button to Increment Counter -->
<button hx-post="{% url 'increment_counter' %}" hx-target="#counter" hx-swap="outerHTML">
    Increment Counter
</button>

</body>
</html>

In this Django template, we have a simple layout with a heading displaying the current counter value and a button to increment the counter. Notice the usage of HTMX attributes like hx-get, hx-post, hx-target, and hx-swap for handling AJAX requests.

Now, let's create the Django views and URLs to handle these HTMX requests and manage the counter:

# Django Views
from django.shortcuts import render
from django.http import JsonResponse

counter_value = 0  # Initial counter value

def get_counter(request):
    # View to retrieve the current counter value
    return JsonResponse({'counter': counter_value})

def increment_counter(request):
    # View to increment the counter and return the updated value
    global counter_value
    counter_value += 1
    return JsonResponse({'counter': counter_value})

And the corresponding Django URLs:

# Django URLs (urls.py)
from django.urls import path
from .views import get_counter, increment_counter

urlpatterns = [
    path('get_counter/', get_counter, name='get_counter'),
    path('increment_counter/', increment_counter, name='increment_counter'),
    # Add other URLs as needed
]

Make sure to include these URLs in your main urls.py file.

Polling with Django and HTMX:

Polling is when a client requests a particular piece of data at regular intervals (maybe every x seconds) and the server reverts with a usual response with the required data. This can be useful on an collaborative/team application, where a user's action needs to be reflected on other's screen. Below is an example:

Let's say we need to Implement a Kanban board in some sort of Development software. In a kanban board, anyone involved in the development should be able to transfer a to-do from one column to another. But having it accurately reflect on other developer's screen is hard. we can either have the user manually reload the page to see any changes or start setting up a websocket & debugging inevitable bugs in the websocket. Here HTMX is the best solution. We will do Poll the state of kanban board in regular intervals (2s).

<div class="htmx-poller" 
    hx-target="#board" 
    hx-swap="innerHTML" 
    hx-get="{% url 'get_board' board.id %}"
    hx-trigger="every 2s"> </div>

<div id = "board" > </div>

In above code snippet. we are getting the the board from the server every 2s and replacing the response with whatever was inside the board div.

hx-target --> the element that is targetted for swapping with the response
hx-get --> sends a get req to the 'get_board' url
hx-swap --> specified what to do with pre existing html inside of the target element
hx-trigger --> specifies when the request should be sent

For our purpose. our web server's code should look like this:

#urls.py 
from django import path 
from views import get_board

urlpatterns = [
    path('board/<int:id>',get_board,name='get_board'),
]

from django.shortcuts import render 

def get_board(request,id):
    #
    #
    return render(request,'path_to_board_component.html',context)

When we return render our board component, it will go to our hx-target which happens to be #board in our case and it will replace previously existing board

Conclusion:

Reject React.JS embrace HTMX

Django, a high-level Python web framework, empowers developers to build robust and scalable web applications efficiently. One of the key aspects that make Django powerful is its support for database relationships. In this article, we will delve into the intricacies of database relationships in Django, exploring how they work and how they can be leveraged to design sophisticated and well-organized applications.
Learn Python & Django at django-tutorial.dev

Understanding Models:

At the core of Django's database functionality are models. Models define the structure of your data, essentially acting as a blueprint for how information will be stored in the database. Django provides a range of field types to define different types of data, such as CharField for characters, IntegerField for integers, and DateTimeField for date and time information.

Creating Models:

To establish a database relationship in Django, it's crucial to create models that accurately represent the entities in your application. For instance, if you are developing a blog application, you might have models for 'Author,' 'Post,' and 'Comment.' By establishing relationships between these models, you can organize and connect your data effectively.

Types of Database Relationships:

Django supports three main types of database relationships: OneToOne, ForeignKey, and ManyToMany.

1. OneToOne Relationship:

   The OneToOneField is a type of field in Django models that establishes a one-to-one relationship between two models. This means that each record in one model is directly related to exactly one record in another model, and vice versa. This type of relationship is useful in scenarios where each instance of one model corresponds to a single instance of another model.

   Creating a OneToOneField:

   To illustrate the usage of OneToOneField, let's consider a common example: a user and a user profile. Each user has a unique profile, and each profile is associated with a single user. Here's how you can define this relationship in Django models:

    from django.db import models
   
    class User(models.Model):
        username = models.CharField(max_length=50)
   
    class UserProfile(models.Model):
        user = models.OneToOneField(User, on_delete=models.CASCADE)
        bio = models.TextField()
   

   In this example, the UserProfile model has a OneToOneField named user that links to the User model. The on_delete attribute is crucial here and determines the behavior when the referenced user is deleted. In this case, models.CASCADE is used, meaning that if a user is deleted, their corresponding user profile will also be deleted.

   Attributes of OneToOneField:

   1. on_delete:
      As mentioned earlier, the on_delete attribute is mandatory for a OneToOneField. It specifies the behavior when the referenced object is deleted. Options include CASCADE, PROTECT, SET_NULL, SET_DEFAULT, SET(), and DO_NOTHING. Choosing the right option depends on the requirements of your application.

   2. limit_choices_to:

      • The limit_choices_to attribute restricts the available choices for the OneToOneField based on a condition. For instance, if you want to limit the available profiles to only those with a certain condition, you can use:

          class UserProfile(models.Model):
              user = models.OneToOneField(User, on_delete=models.CASCADE, limit_choices_to={'is_staff': True})
              bio = models.TextField()
        

        Here, only user profiles where the associated user is a staff member will be available as choices.

   3. related_name:

      • The related_name attribute allows you to set the name of the reverse relation from the referenced model back to the model that defines the OneToOneField. This can be handy when you want to access the reverse relation easily. For example:

          class UserProfile(models.Model):
              user = models.OneToOneField(User, on_delete=models.CASCADE, related_name='profile')
              bio = models.TextField()
        

        Now, you can access a user's profile using user.profile.

   4. parent_link:

      • The parent_link attribute, when set to True, creates an additional hidden field to store the relationship between the models. This can be useful in certain scenarios, but it's not commonly used.

   5. unique:

      • The unique attribute, when set to True, enforces that each instance of the model with a OneToOneField has a unique related object. This is similar to adding a unique constraint to the database.

Putting it All Together:

Now that we've explored the attributes of OneToOneField, let's see how they can be combined to create a flexible and efficient data model. Continuing with our user and user profile example, we might have the following:

    class User(models.Model):
        username = models.CharField(max_length=50)

    class UserProfile(models.Model):
        user = models.OneToOneField(User, on_delete=models.CASCADE, related_name='profile', limit_choices_to={'is_staff': True}, unique=True)
        bio = models.TextField()

In this setup:

• on_delete ensures that when a user is deleted, their profile is also deleted.

• related_name makes it easy to access a user's profile using user.profile.

• limit_choices_to restricts the available choices to only user profiles where the associated user is a staff member.

• unique ensures that each user has a unique profile.

Mastering OneToOneField in Django opens up a world of possibilities for designing clean and efficient data models. Understanding the attributes such as on_delete, related_name, limit_choices_to, parent_link, and unique allows developers to tailor the behavior of the OneToOneField to fit the specific needs of their applications. As you embark on your journey as a Django developer, incorporating these concepts into your projects will contribute to building robust and well-organized applications.\

2. ForeignKey Relationship:

   A ForeignKey is a field in a Django model that creates a many-to-one relationship between two models. This relationship signifies that each record in the referencing model (the model containing the ForeignKey) is associated with exactly one record in the referenced model. This type of relationship is particularly useful when modeling scenarios where entities are interconnected, such as the relationship between authors and their books in a library application.

   Creating a ForeignKey Relationship:

   To illustrate the usage of ForeignKey, let's consider a common example: a blog application where each post is associated with an author. Here's how you can define this relationship in Django models:

    from django.db import models
   
    class Author(models.Model):
        name = models.CharField(max_length=100)
   
    class Post(models.Model):
        title = models.CharField(max_length=200)
        content = models.TextField()
        author = models.ForeignKey(Author, on_delete=models.CASCADE)
   

   In this example, the Post model has a ForeignKey named author that references the Author model. The on_delete attribute is crucial and specifies what should happen when the referenced author is deleted. In this case, models.CASCADE is used, indicating that if an author is deleted, all of their associated posts will also be deleted.

   Attributes of ForeignKey:

   1. on_delete:

      • The on_delete attribute is mandatory for a ForeignKey and determines the behavior when the referenced object is deleted. As mentioned earlier, options include CASCADE, PROTECT, SET_NULL, SET_DEFAULT, SET(), and DO_NOTHING. Choosing the right option is crucial for maintaining data integrity and preventing unexpected behavior.

   2. related_name:

      • Similar to the OneToOneField, the related_name attribute allows you to set the name of the reverse relation from the referenced model back to the model that defines the ForeignKey. This is useful when you want to access the reverse relation easily. For example:

          class Post(models.Model):
              title = models.CharField(max_length=200)
              content = models.TextField()
              author = models.ForeignKey(Author, on_delete=models.CASCADE, related_name='posts')
        

        Now, you can access an author's posts using author.posts.

   3. related_query_name:

      • The related_query_name attribute allows you to specify the name to use for the reverse relation from the referenced model to the model that defines the ForeignKey. This is useful when performing queries. For example:

          class Author(models.Model):
              name = models.CharField(max_length=100)
        
          class Post(models.Model):
              title = models.CharField(max_length=200)
              content = models.TextField()
              author = models.ForeignKey(Author, on_delete=models.CASCADE, related_query_name='post')
        

        Now, you can use Author.objects.filter(post__title__icontains='Django') to filter authors based on their posts.

   4. limit_choices_to:

      • The limit_choices_to attribute restricts the available choices for the ForeignKey based on a condition. For instance, if you want to limit the available authors to only those with a certain condition, you can use:

          class Post(models.Model):
              title = models.CharField(max_length=200)
              content = models.TextField()
              author = models.ForeignKey(Author, on_delete=models.CASCADE, limit_choices_to={'is_published': True})
        

        Here, only authors with the specified condition (is_published=True) will be available as choices.

   5. to_field:

      • The to_field attribute allows you to specify the field on the related model that should be used as the target of the ForeignKey. This can be useful when you want to establish the ForeignKey relationship with a field other than the primary key. For example:

          class Author(models.Model):
              name = models.CharField(max_length=100)
              email = models.EmailField(unique=True)
        
          class Post(models.Model):
              title = models.CharField(max_length=200)
              content = models.TextField()
              author = models.ForeignKey(Author, on_delete=models.CASCADE, to_field='email')
        

        Here, the email field in the Author model is used as the target field for the ForeignKey.

   6. db_constraint:

      • The db_constraint attribute, when set to False, disables the database constraint for the ForeignKey. This means that the database won't enforce referential integrity, allowing you to have references to non-existent rows. While this can be useful in certain scenarios, it should be used cautiously to avoid data inconsistencies.

Putting it All Together:

Let's explore how these attributes can be combined to create a flexible and efficient data model. Continuing with our blog example, we might have the following:

    class Author(models.Model):
        name = models.CharField(max_length=100)
        is_published = models.BooleanField(default=True)

    class Post(models.Model):
        title = models.CharField(max_length=200)
        content = models.TextField()
        author = models.ForeignKey(Author, on_delete=models.CASCADE, related_name='posts', related_query_name='post', limit_choices_to={'is_published': True}, to_field='name', db_constraint=False)

In this setup:

• on_delete ensures that when an author is deleted, all of their associated posts are also deleted.

• related_name allows easy access to an author's posts using author.posts.

• related_query_name provides a clear way to perform queries on the reverse relation (Author.objects.filter(post__title__icontains='Django')).

• limit_choices_to restricts the available authors to only those with the specified condition (is_published=True).

• to_field specifies the field on the related model (Author) that should be used as the target of the ForeignKey (name in this case).

• db_constraint=False disables the database constraint for the ForeignKey.

In this article, we've explored the power of ForeignKey in Django and its attributes that shape the behavior of the relationship. Understanding how to leverage on_delete, related_name, related_query_name, limit_choices_to, to_field, and db_constraint empowers developers to design intricate and efficient data models tailored to the specific requirements of their applications. As you embark on your journey as a Django developer, incorporating these concepts into your projects will contribute to building scalable and maintainable web applications.

3. ManyToMany Relationship:

   A ManyToManyField in Django establishes a many-to-many relationship between two models, allowing each record in one model to be associated with multiple records in another model, and vice versa. This type of relationship is common in scenarios where entities can have multiple connections with each other, such as the relationship between students and courses in an education system.

   Creating a Many-to-Many Relationship:

   To illustrate the usage of ManyToManyField, let's consider a classic example: a music application where each artist can be associated with multiple genres, and each genre can be linked to multiple artists. Here's how you can define this relationship in Django models:

    from django.db import models
   
    class Artist(models.Model):
        name = models.CharField(max_length=100)
        genres = models.ManyToManyField('Genre')
   
    class Genre(models.Model):
        name = models.CharField(max_length=50)
   

   In this example, the Artist model has a ManyToManyField named genres that references the Genre model. This allows an artist to be associated with multiple genres, and a genre to be linked to multiple artists.

   Attributes of ManyToManyField:

   1. symmetrical:

      • The symmetrical attribute, by default set to True, implies that if an instance of model A is related to an instance of model B, then the reverse is also true. In our music application example, if an artist is associated with a genre, then that genre is also associated with the artist. Setting symmetrical to False can be useful in scenarios where the relationship between the two models is not necessarily reciprocal.

        class Artist(models.Model):
            name = models.CharField(max_length=100)
            genres = models.ManyToManyField('Genre', symmetrical=False)

2. through:

   • The through attribute allows the creation of a custom intermediary model for the many-to-many relationship. This intermediary model can have additional fields, providing more flexibility and control over the relationship.

        class Membership(models.Model):
            artist = models.ForeignKey(Artist, on_delete=models.CASCADE)
            genre = models.ForeignKey(Genre, on_delete=models.CASCADE)
            date_joined = models.DateField()

        class Artist(models.Model):
            name = models.CharField(max_length=100)
            genres = models.ManyToManyField('Genre', through='Membership')

        class Genre(models.Model):
            name = models.CharField(max_length=50)

Here, the Membership model serves as the intermediary model with an additional field date_joined, allowing you to track when an artist joined a particular genre.

3. related_name:

   • Similar to ForeignKey, the related_name attribute allows you to set the name of the reverse relation from the referenced model back to the model that defines the ManyToManyField. This is useful when you want to access the reverse relation easily.

        class Artist(models.Model):
            name = models.CharField(max_length=100)
            genres = models.ManyToManyField('Genre', related_name='artists')

Now, you can access all artists associated with a genre using genre.artists.all().

4. related_query_name:

   • The related_query_name attribute allows you to specify the name to use for the reverse relation from the referenced model to the model that defines the ManyToManyField when performing queries.

        class Genre(models.Model):
            name = models.CharField(max_length=50)
            artists = models.ManyToManyField('Artist', related_query_name='artist')

Now, you can use Genre.objects.filter(artist__name__icontains='John') to filter genres based on the associated artists.

5. limit_choices_to:

   • The limit_choices_to attribute restricts the available choices for the ManyToManyField based on a condition.

        class Artist(models.Model):
            name = models.CharField(max_length=100)
            genres = models.ManyToManyField('Genre', limit_choices_to={'is_active': True})

Here, only active genres will be available as choices for the artist.

6. symmetrical:

   • In addition to the symmetrical attribute mentioned earlier, the ManyToManyField also has a symmetrical option that can be set to False on one side of the relationship to indicate that the reverse relation should not be created. This is useful when dealing with scenarios where the relationship is asymmetrical.

        class Artist(models.Model):
            name = models.CharField(max_length=100)
            genres = models.ManyToManyField('Genre', symmetrical=False)

Putting it All Together:

Let's explore how these attributes can be combined to create a flexible and efficient data model. Continuing with our music application example, we might have the following:

    class Membership(models.Model):
        artist = models.ForeignKey(Artist, on_delete=models.CASCADE)
        genre = models.ForeignKey(Genre, on_delete=models.CASCADE)
        date_joined = models.DateField()

    class Artist(models.Model):
        name = models.CharField(max_length=100)
        genres = models.ManyToManyField('Genre', through='Membership', related_name='artists', related_query_name='artist', limit_choices_to={'is_active': True}, symmetrical=False)

    class Genre(models.Model):
        name = models.CharField(max_length=50)
        is_active = models.BooleanField(default=True)

In this setup:

• through='Membership' introduces an intermediary model for the many-to-many relationship, allowing us to store additional information like the date_joined.

• related_name and related_query_name make it convenient to access the reverse relation from both sides of the relationship.

• limit_choices_to restricts the available genres for an artist to only those that are active.

• symmetrical=False indicates that the relationship is not necessarily reciprocal, allowing for asymmetrical connections.

In this article, we've delved into the ManyToManyField in Django and its various attributes that shape the behavior of many-to-many relationships. Understanding how to use symmetrical, through, related_name, related_query_name, limit_choices_to, and symmetrical allows developers to create intricate and flexible data models that accurately represent the complex relationships in their applications. As you navigate the landscape of Django development, incorporating these concepts into your projects will empower you to build scalable and well-organized web applications.

Conclusion:

In this article, we've explored the fundamental concepts of database relationships in Django. Understanding how to leverage OneToOne, ForeignKey, and ManyToMany relationships allows developers to design complex and interconnected applications with ease. As you continue your journey into Django development, mastering these relationships will be essential for building scalable and maintainable web applications.

Django, a high-level web framework written in Python, empowers developers to create robust and scalable web applications. One of the fundamental components of building interactive web forms in Django is its powerful form handling system. Django forms provide a seamless way to handle user input, validate data, and simplify the process of creating HTML forms.

Learn Python & Django at django-tutorial.dev

Understanding Django Forms

In Django, a form is a Python class that defines the fields and behavior of the form. These fields can be as simple as a text input or as complex as a file upload. Django forms take care of rendering HTML, validating data, and handling user input.

Creating a Basic Form

Let's start by creating a simple Django form. Consider a scenario where you want to collect user information, such as their name and email.

# forms.py
from django import forms

class UserForm(forms.Form):
    name = forms.CharField(label='Your Name', max_length=100)
    email = forms.EmailField(label='Your Email')

Here, we define a UserForm class that inherits from forms.Form. The form has two fields: name and email. The CharField and EmailField are examples of form fields provided by Django.

Rendering Forms in Views

Now that we have our form, let's see how to use it in a view. Below is a simple view that renders the form and handles the form submission.

# views.py
from django.shortcuts import render, redirect
from .forms import UserForm

def user_info(request):
    if request.method == 'POST':
        form = UserForm(request.POST)
        if form.is_valid():
            # Do something with the valid form data
            return redirect('success_page')
    else:
        form = UserForm()

    return render(request, 'user_info.html', {'form': form})

In this view, we instantiate the UserForm class. If the request method is POST, it means the form is being submitted, so we validate the form. If the form is valid, we can perform actions with the submitted data.

HTML Template for Form Rendering

To render the form in an HTML template, create a template named user_info.html.

<!-- user_info.html -->
<form method="post" action="{% url 'user_info' %}">
    {% csrf_token %}
    {{ form.as_p }}
    <button type="submit">Submit</button>
</form>

Here, {{form.as_p }} automatically renders the form fields as paragraphs. Django takes care of rendering the HTML based on the form definition. Note that {%csrf_token%} is a context processor available to all templates. Read about context processors here . You can use @csrf_exempt decorator in your function if you dont want to use csrf_token context processor. Read more about decorators here

Validating Data with Django Forms

Django forms come with built-in validators that make it easy to ensure the submitted data meets certain criteria.

Custom Validation

Suppose you want to ensure that the user's name does not contain numbers. You can add a custom validator to the name field in the UserForm class.

# forms.py
from django.core.exceptions import ValidationError

def validate_no_numbers(value):
    if any(char.isdigit() for char in value):
        raise ValidationError('Name cannot contain numbers.')

class UserForm(forms.Form):
    name = forms.CharField(label='Your Name', max_length=100, validators=[validate_no_numbers])
    email = forms.EmailField(label='Your Email')

Now, if a user tries to submit a name with numbers, the form will be considered invalid, and an appropriate error message will be displayed.

Enhancing Forms with Widgets

Django provides widgets to customize the HTML rendering of form fields. Let's enhance our UserForm by adding a date of birth field with a DateInput widget.

# forms.py
from django.forms import DateInput

class UserForm(forms.Form):
    name = forms.CharField(label='Your Name', max_length=100)
    email = forms.EmailField(label='Your Email')
    dob = forms.DateField(label='Date of Birth', widget=DateInput(attrs={'type': 'date'}))

In this example, the DateInput widget is used to render the date field as an input with a date picker.

Adding Classnames and Styling to Django Forms

Ensuring that your Django forms not only function well but also look visually appealing is crucial for providing a positive user experience. Django allows you to customize the rendering of form elements by adding classnames and styling through the use of widgets and HTML attributes. Let's explore how you can enhance the appearance of your forms.

Styling Form Fields with Classnames

You can add custom classnames to form fields to apply specific styles. This is particularly useful when you want to customize the appearance of individual fields or apply a consistent style across your forms.

# forms.py
class UserForm(forms.Form):
    name = forms.CharField(label='Your Name', max_length=100, widget=forms.TextInput(attrs={'class': 'custom-input'}))
    email = forms.EmailField(label='Your Email', widget=forms.EmailInput(attrs={'class': 'custom-input'}))
    dob = forms.DateField(label='Date of Birth', widget=DateInput(attrs={'type': 'date', 'class': 'custom-input'}))

In the above example, the custom-input class is added to each form field, allowing you to target and style them in your CSS.

Applying Overall Form Styles

To style the form as a whole, you can utilize the form element in your HTML template and assign a class to it.

<!-- user_info.html -->
<form method="post" action="{% url 'user_info' %}" class="custom-form">
    {% csrf_token %}
    {{ form.as_p }}
    <button type="submit" class="custom-button">Submit</button>
</form>

In this case, the form has been assigned the custom-form class, and the submit button has the custom-button class. This allows you to apply specific styles to the entire form or individual elements.

Writing CSS Styles for Custom Classes

Now that you've added custom classnames to your form elements, it's time to define the styles in your CSS file. Create a CSS file (e.g., styles.css) and link it in your HTML template.

/* styles.css */
.custom-input {
    /* Add your custom styles for form fields here */
    border: 1px solid #ccc;
    padding: 8px;
}

.custom-form {
    /* Add overall form styles here */
    max-width: 400px;
    margin: 0 auto;
}

.custom-button {
    /* Add styles for the submit button here */
    background-color: #4CAF50;
    color: white;
    padding: 10px 15px;
    border: none;
    cursor: pointer;
}

Ensure that the CSS file is properly linked in your HTML template. With these styles, you have the flexibility to create a visually appealing and cohesive design for your Django forms.

Topics to Explore on your own:

1. Existence of FreeWill (if it exists)

2. Creating a form for a modal and using widget to stylize the fields and add more properties like required, multiple, placeholder etc

3. Using init function to loop through all fields of the form customizing them

4. Overriding default functions like save and cleaned_data

Conclusion

Django forms are a powerful tool for handling user input in web applications. Whether you're collecting simple information or dealing with complex data, Django forms simplify the process of validation, rendering HTML, and processing user input. As you delve deeper into Django development, mastering the intricacies of forms will undoubtedly contribute to the efficiency and robustness of your web applications. Suffer coding!

This is your 7/900 Steps in becoming a Django Master jr.

Django, a web framework written in Python, is celebrated for its simplicity and flexibility. One of the powerful features that contribute to this reputation is decorators. Decorators in Django allow developers to modify or extend the behavior of functions or methods effortlessly. In this blog post, we'll embark on a journey to master Django decorators, exploring their basics, common use cases, and advanced patterns.

Learn Python & Django at django-tutorial.dev

Understanding Python Decorators

Before diving into Django-specific decorators, it's essential to understand Python decorators in general. In Python, a decorator is a function that takes another function and extends or modifies its behavior. Decorators are denoted with the @ symbol and are placed above the function they decorate.

# A simple decorator
def my_decorator(func):
    def wrapper():
        print("Something is happening before the function is called.")
        func()
        print("Something is happening after the function is called.")
    return wrapper

@my_decorator
def say_hello():
    print("Hello!")

say_hello()

"""
The output will be:

    Something is happening before the function is called.
    Hello!
    Something is happening after the function is called.

"""

In this example, my_decorator is a simple decorator that adds behavior before and after the say_hello function is called.

Django View Decorators

In Django, decorators are widely used to enhance the functionality of views. Let's explore some common view decorators and their applications.

@login_required

The @login_required decorator ensures that a view can only be accessed by authenticated users. If a user is not logged in, they are redirected to the login page.

from django.contrib.auth.decorators import login_required

@login_required
def my_secure_view(request):
    # Your view logic here
    return render(request, 'secure_page.html')

This decorator simplifies the process of securing views that require user authentication.

@permission_required

Similar to @login_required, the @permission_required decorator checks if a user has specific permissions to access a view.

from django.contrib.auth.decorators import permission_required

@permission_required('myapp.can_view_data')
def restricted_data_view(request):
    # Your view logic here
    return render(request, 'restricted_data.html')

This decorator is useful when you need to control access based on custom permissions defined in your Django app aka Roles of User. This will be handy when you are creating a platform where there are more than 1 types of users like admin, management, employee & Clients.

Custom Decorators

While Django provides useful built-in decorators, you'll often find the need to create your own custom decorators to encapsulate reusable functionality.

Creating an Underrated Decorator

I don't want any supporter of UML( political party) to access my site. I can create a custom decorator to Respond to UML supporters with a message while giving anyone else complete access to my web app. I am going to just respond the text.
"YOU ARE THE PROBLEM"

#    app/decorators.py
from django.http import HttpResponse

def get_help(view_func):
    def wrapper(request,*args,**kwargs):
        if request.user.name in uml_supporter_list: #this is already documented list
            return HttpResponse("YOU ARE THE PROBLEM")
        else:
            view_func(request,*args,**kwargs)
        return wrapper

Now, I can use @get_help to decline any UML supporters of my Web Service

from app.decorators import get_help
from django.shortcuts import render

@get_help
def index(request):
    return render(request,'app/index.html')

Creating a Logging Decorator

Let's say you want to log information about the arguments and return value of a view. You can create a custom logging decorator for this purpose. Below is a code for File based logging using python's built in module called 'logging'. For Django decorators the wrapper needs to take request, *args and **kwargs as parameter in most cases.

#    app/decorators.py
import logging

# Configure the logging settings (add this to your settings.py or another configuration file)
logging.basicConfig(filename='views.log', level=logging.INFO, format='%(asctime)s - %(levelname)s - %(message)s')

def log_view(func):
    def wrapper(request, *args, **kwargs):
        # Log information before calling the view
        log_message = f"{request.user} is calling {func.__name__} with arguments: {args}, {kwargs}"
        logging.info(log_message)

        result = func(request, *args, **kwargs)

        # Log information after calling the view
        log_message = f"{func.__name__} returned: {result}"
        logging.info(log_message)

        return result
    return wrapper

Now, you can use @log_view to add logging to any view.

from app.decorators import log_view

@log_view
def my_logged_view(request):
    # Your view logic here
    return render(request, 'logged_page.html')

Handling Function Arguments in Decorators

Sometimes, you might need decorators that accept arguments. This can be achieved by adding an extra layer of nested functions.

#    app/decorators.py
def custom_decorator(arg1, arg2):
    def decorator(func):
        def wrapper(*args, **kwargs):
            # Custom logic using arg1 and arg2
            result = func(*args, **kwargs)
            # Additional logic if needed
            return result
        return wrapper
    return decorator

Now, when applying the decorator, you provide arguments like so:

from app.decorators import custom_decorator
@custom_decorator(arg1='value1', arg2='value2')
def my_decorated_function():
    # Your function logic here
    pass

This pattern allows decorators to be flexible and adaptable to various scenarios.

Advanced Decorator Patterns

As you delve deeper into Django development, you may encounter advanced decorator patterns that leverage class-based views or mixins. For example, the @method_decorator allows applying decorators to specific HTTP methods.

from django.utils.decorators import method_decorator
from django.views import View

@method_decorator(login_required, name='dispatch')
class MySecureView(View):
    # Your view logic here

This ensures that the login_required decorator is only applied to the dispatch method of the class-based view.

Conclusion

Mastering Django decorators opens the door to elegant and modular code. Whether you're securing views, logging information, or creating custom functionality, decorators provide a clean and Pythonic way to enhance your web development experience. As you continue your Django journey, experimenting with and understanding decorators will undoubtedly contribute to the efficiency and maintainability of your codebase. Suffer decorating!

This is your 6/900 Steps in becoming a Django Master jr.

To a Master like me, SMTP stands for Send Mail To Peasants. But to a peasant like you, SMTP should stand for Simple Mail Transfer Protocol. It is the standard Protocol followed by emailing systems. You will be using Gmail's SMTP server to send the mail as it doesn't require your project to be hosted.

Learn Python & Django at django-tutorial.dev

Setting up Django for Email

1. Install Django & decouple

If you haven't already, install Django and decouple using the following commands:

pip install Django
pip install python-decouple

2. Setting up Variables

You will need an App Password for your gmail account to use gmail's smtp. For this:

1. Goto your Google Accounts Security settings here

2. Turn on 2 Factor Authentication (2FA)

3. Goto App Passwords and create an app password

4. Copy the Password and securely store it somewhere.

After You have the App password, create an .env file that will have your environment variables for development stage. I have explained what this does in this Blog. This is what .env file should look like:

EMAIL_HOST_USER='django@master.com'
EMAIL_HOST_PASSWORD'xxxx xxxx xxxx xxxx'

3. Configure Email Settings

In your Django project settings (settings.py), find the EMAIL_BACKEND setting and set it to 'django.core.mail.backends.smtp.EmailBackend'. Also, configure the SMTP settings for Gmail:

# settings.py
from decouple import config
# Email settings
EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend'
EMAIL_HOST = 'smtp.gmail.com'
EMAIL_PORT = 587
EMAIL_USE_TLS = True
EMAIL_HOST_USER = config('EMAIL_HOST_USER')  # Your Gmail email address
EMAIL_HOST_PASSWORD = config('EMAIL_HOST_PASSWORD')  # Your Gmail email password or app password

Values in EMAIL_HOST_USER and EMAIL_HOST_PASSWORD will be replaced by decouple with your actual Gmail credentials from '.env' file. Note: It's recommended to use an app password for better security.

Writing the Django View

Now, let's create a simple Django view that sends an email when accessed.

1. Import Required Modules

In your views.py file, import the necessary modules:

# views.py

from django.core.mail import send_mail
from django.http import HttpResponse

2. Create the Email-Sending View

Add a function in your views.py to handle email sending:

# views.py
from decouple import config
from django.core.mail import send_mail

def send_email_view(request):
    to_email = request.user.email
    subject = 'Hello from Your Django App'
    message = 'This is a test email sent from your Django app.'
    from_email = config('EMAIL_HOST_USER')  # Sender's email address
    recipient_list = [to_email]  # Recipient's email address

    send_mail(subject, message, from_email, recipient_list)

    return HttpResponse('Email sent successfully!')

You can also research on sending html files as the email message that will render on the receiver's end to prettify your emails.

URLs and Testing

Finally, configure a URL for your new view in your urls.py:

# urls.py
from django.urls import path
from .views import send_email_view

urlpatterns = [
    path('send_email/', send_email_view, name='send_email'),
]

Now, run your Django development server and navigate to http://localhost:8000/send_email/ to trigger the email-sending view. Check the console for any errors, and if everything is set up correctly, you should see the 'Email sent successfully!' message.

Conclusion

Congratulations! You've successfully set up email functionality in your Django project using Gmail's SMTP server. This is a basic example, and you can expand upon it by customizing the email content, handling attachments, or incorporating email templates.

Additionally, you may want to explore Django's built-in support for sending HTML emails and managing email templates for a more professional and customizable approach. Suffer Coding!

This is your 5/900 Steps in becoming a Django Master jr.

Learn Python & Django at django-tutorial.dev

Common Mistakes:

1. Vulnerable SECRET_KEY:

   One of the prevalent mistakes I encounter is the exposure of the SECRET_KEY. This crucial piece of information should always be guarded with the utmost care.

2. Vulnerable API_KEY:

   Similar to SECRET_KEY, API_KEYs are often left unprotected. This oversight can lead to potential security breaches, compromising the integrity of your project.

3. Vulnerable DATABASE:

   Exposing database credentials is another pitfall. It's essential to shield this sensitive information from prying eyes to prevent unauthorized access.

4. Using Class Based Views (NEVER USE IT):

   While not a security risk per se, It is Risking Yourself to Brain Damage just by it's Use or by someone else when they are trying to box you.
   NEVER USE CLASS BASED VIEW

5. Vulnerable DEBUG status:

   Keeping the DEBUG mode on in a production environment is a significant security flaw. This can expose sensitive information and open the door to potential exploits.

6. Vulnerable DATA:

   Mishandling and exposing critical data within your project can have severe consequences. Proper precautions must be taken to ensure data security.

Preventing Mistakes

To tackle these common mistakes, I recommend employing a robust solution – Python-decouple.

Python-decouple:

Python-decouple is a Django package that advocates for a strict separation of settings from code. The solution lies in creating a .env file housing crucial information such as SECRET_KEY, API_KEY, DEBUG status, SMTP credentials, and external database URLs. By utilizing the config(data_name) method, these values can be accessed from the .env file, ensuring a secure and modular approach.

Why not just Use environment variables and the os.environ method like in python?

Cause It will only return String. and we might need to get a Boolean or some other type of data and stop being so stupid.

example code for .env file:

# .env
SECRET_KEY=my_super_secret_key
DEBUG=True 
# Database
DATABASE_URL=postgresql://your_db_user:your_db_password@localhost/your_db_name

# Email settings
EMAIL_HOST=your_email_host
EMAIL_PORT=your_email_port
EMAIL_USE_TLS=True
EMAIL_HOST_USER=your_email_username
EMAIL_HOST_PASSWORD=your_email_password

Example code for the settings.py:

# settings.py

from decouple import config

# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = config('SECRET_KEY')

# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = config('DEBUG', default=False, cast=bool)

# Database
# https://docs.djangoproject.com/en/3.2/ref/settings/#databases

DATABASES = {
    'default': config('DATABASE_URL',cast = str),
}

# Email settings
EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend'
EMAIL_HOST = config('EMAIL_HOST')
EMAIL_PORT = config('EMAIL_PORT', cast=int)
EMAIL_USE_TLS = config('EMAIL_USE_TLS', default=True, cast=bool)
EMAIL_HOST_USER = config('EMAIL_HOST_USER')
EMAIL_HOST_PASSWORD = config('EMAIL_HOST_PASSWORD')

If You are Using the code from your github repo in production, then you need to either create a .env file inside of the root directory of your production environment.

How does it work?

Decouple always searches for Options in this order:

1. Environment variables;

2. Repository: ini or .env file;

3. Default argument passed to config.

Understanding the CAST argument

By default, all values returned by decouple are strings, after all they are read from text files or the environment.

However, your Python code may expect some other value type, for example:

• Django’s DEBUG expects a boolean True or False.

• Django’s EMAIL_PORT expects an integer.

• Django’s ALLOWED_HOSTS expects a list of hostnames.

• Django’s SECURE_PROXY_SSL_HEADER expects a tuple with two elements, the name of the header to look for and the required value.

Did you really need to read this? Maybe you are slow...

Implementation:

1. Create a .env file with sensitive data.

2. Use Python-decouple's config(data_name) method to access values.

3. Configure your version control system (Git) to ignore the .env file, preventing inadvertent exposure.

By adopting Python-decouple and implementing a .env file, you fortify your project against several vulnerabilities in one fell swoop. This proactive approach not only enhances security but also fosters good development practices.

This is your 4/900 Steps in becoming a Django Master jr.

Understanding React.js and Django: Before diving into the integration process, let's briefly understand the strengths of React.js and Django.

React.js is a JavaScript library for building user interfaces, particularly for single-page applications where updates occur frequently. It allows developers to create reusable UI components, making the code modular and easy to maintain. React's virtual DOM efficiently updates only the necessary components, optimizing performance.

On the other hand, Django is a high-level Python web framework known for its simplicity, flexibility, and scalability. It follows the Model-View-Controller (MVC) architectural pattern, promoting clean and organized code. Django excels in handling server-side logic, managing databases, and routing requests.

Learn Python & Django at django-tutorial.dev

Why Integrate React.js with Django?

Integrating React.js with Django leverages the strengths of both technologies. Django handles backend operations, such as database management, authentication, and routing, while React.js takes charge of the frontend, providing a responsive and interactive user interface.

This combination is particularly beneficial for creating complex applications where real-time updates and a seamless user experience are essential. The django-reactjs package streamlines the integration process, making it easier for developers to harness the power of both technologies.

Installing django-reactjs: To get started, install the django-reactjs package using the following command:

pip install django-reactjs

Next, add 'react' to your INSTALLED_APPS in the settings.py file:

INSTALLED_APPS = [
    # ...
    'react',
]

Run migrations to apply the changes:

python manage.py migrate

Setting Up React Components: Create a new folder, let's call it 'frontend,' to store your React components. Inside this folder, initialize a new React app using your preferred method, such as Create React App or manually setting up a project.

Once your React app is set up, you can start building components. Django-Reactjs provides a {% react_component %} template tag to render React components within your Django templates.

Creating Django Views: To connect your Django backend with the React frontend, create views that will render your React components. In your views.py file, import the necessary modules and use the ReactView class provided by Django-Reactjs.

from django.shortcuts import render
from react.views import ReactView

class MyReactView(ReactView):
    template_name = 'index.html'  # Replace with your template name
    component_name = 'MyReactApp'  # Replace with your React component name

Configuring URLs: In your urls.py file, map the URL to the corresponding view.

from django.urls import path
from .views import MyReactView

urlpatterns = [
    path('react-app/', MyReactView.as_view(), name='react-app'),
    # Add other URLs as needed
]

Rendering React Components: Finally, in your Django template (e.g., index.html), use the {% react_component %} template tag to render your React component.

{% extends 'base.html' %}

{% block content %}
    <div id="app">
        {% react_component 'MyReactApp' %}
    </div>
{% endblock %}

Conclusion: Integrating React.js with Django using the Django-Reactjs package is a powerful combination that allows you to build robust and modern web applications. By leveraging the strengths of both technologies, you can create a seamless user experience while benefiting from Django's backend capabilities. Experiment with different React components, explore additional features of Django-Reactjs, and take your web development skills to new heights. Happy coding!

The django-reactjs Package is Deprecated, 😜 Goodluck Creating an API now

Django, a powerful web framework for building web applications using Python, provides a variety of tools to simplify development tasks. One such tool that plays a crucial role in managing data across multiple views and templates is the Context Processor. In this guide, we'll explore what context processors are, how they work, and how to leverage them in Django projects.

Learn Python & Django at django-tutorial.dev

Prerequisites:

1. Nepali Citizenship

2. Tax Clearance certificate

3. Daura-Suruwal (दौरा सुरुवाल)

4. Dhaka Topi

5. Nepali Flag

What is a Context Processor?

In Django, a context processor is a Python function that adds data to the context of every template rendered (like a बिचौलिया {middleman}). The context in Django refers to a dictionary-like object that stores variables accessible within a template.

from django.shortcuts import render,redirect
from .forms import TaskForm

def createtask(request):
    if request.method == 'POST':
        form = TaskForm(request.POST)

        if form.is_valid():
            form.save()
            return redirect('home')
    else:
        form = TaskForm()
        context={
            'form':form
        }
    return render(request,'home/createtask.html',context)

The snippet is from the Best TODO app with the Django Master. In the
render(request,'home/createtask.html',context) line, 'context' is the context that we are
adding to the createtask.html template. Context processors allow you to inject additional data into this context, making it available to all templates across your project.

How Context Processors Work

Context processors are executed every time a template is rendered. They run before the template is rendered, allowing you to include dynamic data in the context. Context processors are often used to include data that is common across multiple views or templates, eliminating the need to pass the same data in each view function.

Here's a step-by-step overview of how context processors work:

1. Creation of the Context: When a view function is called and a template is rendered, Django creates a context, which is essentially a dictionary containing variables.

2. Context Processors Execution: Before the template is rendered, Django executes all registered context processors. These processors can add, modify, or remove variables from the context.

3. Template Rendering: Once the context processors have executed, the updated context is passed to the template engine for rendering. The template can then access the variables in the context.

Creating a Context Processor

Creating a context processor involves defining a Python function that adds data to the context. Follow these steps to create a basic context processor:

1. Create a Python file for Context Processors: Create a file named context_processors.py inside your Django app.

2. Define the Context Processor Function: In context_processors.py, define a function that takes the request as an argument and returns a dictionary containing the data you want to add to the context. For example:

    # myapp/context_processors.py
    def CustomDataNameGoesInHereAreYouBlindBro(request):
        return {'slogan': 'KP OLI murdabad'}
   

3. Register the Context Processor: In your Django project settings (settings.py), add the path to the context processor function to the context_processors list. It should look like:

    # settings.py
    TEMPLATES = [
        {
            'OPTIONS': {
                'context_processors': [
                    'myapp.context_processors.CustomDataNameGoesInHereAreYouBlindBro',
                ],
            },
        },
    ]
   

   Ensure that you replace 'myapp.context_processors.CustomDataNameGoesInHereAreYouBlindBro' with the correct path to your context processor and the correct function name.

Using Context Variables in Templates

Once the context processor is registered, you can use the added variables in your templates. For example, if the context processor adds a variable named slogan, you can access it in a template like this:

<!-- bebsite.html -->
<p>{{ slogan }}</p>

Common Use Cases for Context Processors

Context processors can be employed for various purposes, including:

1. Global Settings: Include global settings that are applicable to all templates, such as site configuration or user preferences.

2. User Authentication: Add information about the current user to the context, making it accessible in templates without explicitly passing it in each view.

3. Dynamic Navigation: Include data for dynamic navigation menus that need to be consistent across multiple pages.

4. SEO Metadata: Inject SEO-related information, such as page titles or meta tags, into the context for better search engine optimization.

Conclusion

Context processors are a powerful tool in the Django framework, enabling developers to manage and share data seamlessly across different views and templates. By understanding how context processors work and leveraging them effectively, you can streamline your code and enhance the consistency and maintainability of your Django projects. You can experiment with context processors in your projects to discover the flexibility and convenience they bring to web development with Django, but you won't go far.

This is your step 3/900 of becoming a Django Master jr.

In The Next Blog we will be discussing about Migrations in Django

Thanks to Kushal subedi for article topic

Learn Python & Django at django-tutorial.dev

What are Static Files?

Static files in Django refer to assets that don't change during the execution of a web application. These can include stylesheets (CSS), JavaScript files, images, and other resources that contribute to the overall look and feel of your site. Unlike dynamic content generated on-the-fly, static files remain constant, providing a consistent user experience.

The Role of Static Files

Static files play a vital role in enhancing the aesthetics and functionality of a web application. They contribute to the user interface, making it visually appealing and interactive. For instance, CSS stylesheets determine the layout and presentation of HTML elements, while JavaScript files add dynamic behavior to the client-side, enabling features like form validation or real-time updates.

Managing Static Files in Django

Django simplifies the handling of static files through the django.contrib.staticfiles app. To get started, ensure that 'django.contrib.staticfiles' is included in the INSTALLED_APPS setting of your project.

1. Directory Structure

Create a static directory within your Django app or project to organize static files. Django follows a convention over configuration approach, so placing static files in this directory ensures they are recognized by the framework.

your_app/
|-- static/
|   |-- your_app/
|       |-- css/
|       |-- js/
|       |-- img/

2. Configuring Static Files

In your project's settings, define the STATIC_URL and STATICFILES_DIRS settings:

# settings.py

STATIC_URL = '/static/'
STATICFILES_DIRS = [
    BASE_DIR / "static",
]

STATIC_URL specifies the base URL for serving static files, while STATICFILES_DIRS points to the location of your static files.

3. Using Static Files in Templates

In your HTML templates, load static files using the {% static %} template tag:

<!-- example.html -->

<!DOCTYPE html>
<html>
<head>
    <link rel="stylesheet" href="{% static 'your_app/css/style.css' %}">
</head>
<body>
    <!-- Your HTML content here -->
    <script src="{% static 'your_app/js/script.js' %}"></script>
</body>
</html>

4. Serving Static Files in Django:

In your template you've used the static tag. but Django Server doesn't know what it means. so We need to make sure the Static Files are being served one way or another. There are Two ways to serve Static Files in Django.

1.Development Environment (DEBUG=True):

In your settings.py for development:

# settings.py

DEBUG = True

# Static files (CSS, JavaScript, images)
STATIC_URL = '/static/'
STATICFILES_DIRS = [
    BASE_DIR / "static",
]

With DEBUG=True, Django's built-in development server automatically handles serving static files from the static directory of your apps.

In your template, use the {% static %} tag to reference static files:

<!-- example.html -->

<!DOCTYPE html>
<html>
<head>
    <link rel="stylesheet" href="{% static 'your_app/css/style.css' %}">
</head>
<body>
    <!-- Your HTML content here -->
    <img src="{% static 'your_app/img/example.jpg' %}" alt="Example Image">
</body>
</html>

2. Production Environment (DEBUG=False):

In a production environment, you should use a dedicated web server like Nginx or Apache to serve static files for better performance. You may also consider using WhiteNoise as middleware.

In your settings.py for production:

#settings.py

DEBUG = False

# Static files (CSS, JavaScript, images)
STATIC_URL = '/static/'
STATIC_ROOT = BASE_DIR / "staticfiles"

Before deploying, collect static files:

python manage.py collectstatic

This command gathers static files from each app and places them in the STATIC_ROOT directory.

Configure your production web server (e.g., Nginx) to serve static files directly. For example, in Nginx:

location /static/ {
    alias /path/to/your/staticfiles/;
}

Adjust the path accordingly based on your project structure.

By configuring static file serving appropriately for both development and production, you ensure a smooth delivery of static assets in your Django application.

Additionally You can use Middleware inside of Django to serve the Static Files, read about it below:

Middleware for Serving Static Files in Production

WhiteNoise is a great middleware for serving static files efficiently in a Django application. It's particularly useful for simplicity and ease of integration, making it an excellent choice, especially for smaller projects or when you want a straightforward solution. Here's how you can configure WhiteNoise as middleware in your Django project:

Install WhiteNoise

First, you need to install the whitenoise package. You can do this using pip:

pip install whitenoise

Update Middleware and Static Files Configuration

1. Add 'whitenoise.middleware.WhiteNoiseMiddleware', to the MIDDLEWARE setting in your settings.py:

    # settings.py
   
    MIDDLEWARE = [
        # Other middleware entries
        'whitenoise.middleware.WhiteNoiseMiddleware',
        # ...
    ]
   

2. Configure WhiteNoise to serve static files by adding the following settings:

    # settings.py
   
    # Enable WhiteNoise for serving static files
    STATIC_URL = '/static/'
    STATICFILES_STORAGE = 'whitenoise.storage.CompressedManifestStaticFilesStorage'
   

   The STATICFILES_STORAGE setting is crucial for telling Django to use WhiteNoise's storage backend for handling static files.

Adjusting URL Patterns

Now, you can simplify your urls.py by removing the manual addition of static files using urlpatterns += static(...), as WhiteNoise will take care of this for you.

pythonCopy code# urls.py

from django.contrib import admin
from django.urls import path

urlpatterns = [
    path('admin/', admin.site.urls),
    # Your other URL patterns go here
]

Collect Static Files

Ensure you collect static files before deploying your application:

python manage.py collectstatic

Conclusion

By integrating WhiteNoise as middleware in your Django project, you benefit from a straightforward and efficient solution for serving static files in production. This not only simplifies your configuration but also enhances the performance of your application. As you continue your Django development journey, understanding and utilizing tools like WhiteNoise contribute to building robust and scalable web applications.

This is your 2/900 step in becoming the Django Master

What is T?

T stands for Templates, a Template in Django is a Html File that is used to Generate a GUI for Average stupid user that cant read the console. Templates are written in Templates directory that can be either in Root directory or the App directory and are rendered by views as a response to specific URLs in urls.py.

We will be diving into template Inheritance Directly Like a Sigma

1. Create a Templates directory in the root directory of the project

2. Create a 'base.html' file in this directory. we will be inheriting this html file

3. Create another directory named includes inside of the templates directory. Shit like Sidebar, Header, Footer and more site-wide components are kept in that directory. You will Put header.html in this directory

4. Create a directory named 'home' inside templates directory and create an 'index.html' and 'createtask.html' files. The 'home' directory will help us organize our templates.

5. If you did everything right, which I highly doubt. This is what your directory structure should look like

   

SHIT to Read:

Django Uses JINJA templating Engine for template rendering. Read about it here:
BORING SHIT

How it Works:

In Django the Templates can be inherited, included and more shit like this. Most Rudimentary thing in all of these is Creating Blocks.
we will write base.html and then we will inherit base.html in all other pages and just change the content body and nothing else following DRY concept.

Header.html:

<nav class="navbar navbar-expand-sm navbar-light bg-success">
    <div class="container-fluid">
        <a class="navbar-brand" href="#">To-Do App</a>
        <button class="navbar-toggler" type="button" data-toggle="collapse" data-target="#navbarID"
            aria-controls="navbarID" aria-expanded="false" aria-label="Toggle navigation">
            <span class="navbar-toggler-icon"></span>
        </button>
        <div class="collapse navbar-collapse" id="navbarID">
            <div class="navbar-nav">
                <a class="nav-link " aria-current="page" href="{% url "home" %}">Home</a>
            </div>
            <div class="navbar-nav">
                <a class="nav-link " aria-current="page" href="{% url "createtask" %}">Add a Task</a>
            </div>
        </div>
    </div>
</nav>

href="{% url "home" %}" will be converted into href="/"
href="{% url "createtask" %}" will be converted into href="/createtask/"
This all happens dynamically Thanks to Jinja Templating engine

Base.html:

<!doctype html>
<html lang="en">
    <head>
        <title> Todo|{% block title %}Basefile{% endblock title %}</title>
        <!-- Required meta tags -->
        <meta charset="utf-8" />
        <meta
            name="viewport"
            content="width=device-width, initial-scale=1, shrink-to-fit=no"
        />

        <!-- Bootstrap CSS v5.2.1 -->
        <link
            href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.2/dist/css/bootstrap.min.css"
            rel="stylesheet"
            integrity="sha384-T3c6CoIi6uLrA9TneNEoa7RxnatzjcDSCmG1MXxSR1GAsXEV/Dwwykc2MPK8M2HN"
            crossorigin="anonymous"
        />
    </head>

    <body>
            {% include "includes/header.html" %}
        <main>
            {% block content %}{% endblock content %}
        </main>
        <footer>

        </footer>
        <!-- Bootstrap JavaScript Libraries -->
        <script
            src="https://cdn.jsdelivr.net/npm/@popperjs/core@2.11.8/dist/umd/popper.min.js"
            integrity="sha384-I7E8VVD/ismYTF4hNIPjVp/Zjvgyol6VFvRkX/vR+Vc4jQkC+hVqc2pM8ODewa9r"
            crossorigin="anonymous"
        ></script>

        <script
            src="https://cdn.jsdelivr.net/npm/bootstrap@5.3.2/dist/js/bootstrap.min.js"
            integrity="sha384-BBtl+eGJRgqQAUMxJ7pMwbEyER4l1g+O15P+16Ep7Q9Q+zqX6gSbd85u4mG4QzX+"
            crossorigin="anonymous"
        ></script>
    </body>
</html>

The {% block title %}Basefile{% endblock title %} is called a Block. If we inherit this
file, we can replace the text "Basefile" with a single line of code and no repeating html code.

The {% include "includes/header.html" %} is called a Include. It is similar to inheriting but we can't change any content of the Parent template easily. We are including header for our site in our base.html in this case.

Index.html:

{% extends "base.html" %}

{% block content %}
    <div
        class="container-md"
    >
    <div
        class="table-responsive-md"
    >
        <table
            class="table table-striped-columns table-hover table-borderless table-primary align-middle"
        >
            <thead class="table-light">
                <caption>
                    Task List
                </caption>
                <tr>
                    <th>Task ID</th>
                    <th>Task </th>
                    <th>Expires on</th>
                    <th>Status</th>
                    <th>Actions</th>
                </tr>
            </thead>
            <tbody class="table-group-divider">
                {% for task in tasks %}
                <tr class="table-primary">
                    <td scope="row">{{task.id}}</td>
                    <td>{{task.title}}</td>
                    <td>{% if task.expired %}
                        Task has expired.
                        {% else %}
                        {{task.expires}}
                        {% endif %}</td>
                    <td>
                        {% if task.is_complete %}
                        Task Completed
                        {% else %}
                        Task Pending
                        {% endif %}
                    </td>
                    <td>
                        {% if task.is_complete %}
                        <a class="btn btn-danger" href = {% url 'togglestatus' task_id=task.id %} > Mark as incomplete</a>
                        {% else %}
                        <a  class ="btn btn-success" href = {% url 'togglestatus' task_id=task.id %} > Mark as Complete</a>
                        {% endif %}
                    </td>
                </tr>
                {% endfor %}
            </tbody>
            <tfoot>

            </tfoot>
        </table>
    </div>

    </div>

{% endblock content %}

The {% extends "base.html" %} is what's inheriting the base.html template. now we can change just what's inside of the {% block content %}{% endblock content %} and {% block title %}{% endblock title %} that we wrote on base.html file.

Createtask.html:

{% extends "base.html" %}

{% block content %}
<div class="container">
<form class=" needs-validation form-control" novalidate method="POST">
    {% csrf_token %}
  {{form.as_p}}
    <button class="btn btn-success" type="submit">Submit form</button>
</form>
</div>
{% endblock content %}

The {% csrf_token %} is required by default on every post request. CSRF stands for Cross Site Request Forgery. only Nerds get deep into it. We will just use the csrf_token tag.

For Stupid People:

None of the shit inside {{ }} ,{% %} will be rendered on the response, website. It simply is used for Logic part for the engine.
{% tag %} is called a tag.
{{ variable }} is called a variable.

How to RUN the Server:

1. Open console.

2. Go to the directory that has manage.py file.

3.    py manage.py makemigrations
      py manage.py migrate
   

4.    py manage.py runserver
   

   GOTO your Microsoft EDGE browser. If you're using any other browser, YOU CANNOT BE A DJANGO MASTER.

This Concludes the Multipart BLOG Creating the Best TODO app With the Django Master [3 pts]

What is V?

V stands for Views, a View in Django is a function that is used to Generate a Response for a request. Views are written in views.py and are mapped to specific URLs in urls.py.

1. Create Urls.py inside your "home" directory.

2. Your Functions will be Written in the views.py

3. Create a Forms.py inside your "home" directory. Your directory Structure should look like this:

4. 

   Create a class named "TaskForm" inside your forms.py like so

    from django.forms import ModelForm
    from .models import Task
   
    class TaskForm(ModelForm):
        class Meta:
            model = Task
            fields=['title','expires']
   

5. Create a function named createtask that takes request as a parameter, saves the TaskForm if the request method is POST else just returns some stuff like shown. all of the .html files we are rendering to are called templates which will be the topic of the next blog from the Django Master

    from django.shortcuts import render,redirect
    from .forms import TaskForm
   
    def createtask(request):
        if request.method == 'POST':
            form = TaskForm(request.POST)
   
            if form.is_valid():
                form.save()
                return redirect('home')
        else:
            form = TaskForm()
            context={
                'form':form
            }
        return render(request,'home/createtask.html',context)
   

6. Create a function named togglestatus that will toggle the Boolean value in the "complete" field of Task Model like so

    from django.shortcuts import redirect
    def togglestatus(request,task_id):
        task = Task.objects.get(id=task_id)
        if task.complete==True:
            task.complete=False
        else:
            task.complete=True
        task.save()
        return redirect('home')
   

7. Create list called urlpatterns and map the function to the routes like this.

    from django.urls import path
    from .import views
   
    urlpatterns = [
        path('',views.index,name='home'),
        path('createtask/',views.createtask,name='createtask'),
        path('togglestatus/<int:task_id>/',views.togglestatus,name='togglestatus')
    ]
   

   The name property in the Path() will help us immensely in Templates by just having to remember the name of the URL instead of the whole path. we will use this name by using the {% url 'name' %} in the next Blog

   In the next Blog we will see how the T in MVT architecture works in Django. Till Then, Keep Misinforming People

I will dominate Django Very Hard with No Mercy. In this Blog we are going to create a Database to store our Todo tasks in and perform CRUD operations in that data with the help of Django's default Admin Panel

1. Create virtual environment.

2. Activate the virtual environment.

3. Install Django in the environment.

4. Create a Django Project named Todo.

5. run the Django server

6. 

   Create an app named home & add home to the installed apps list in settings.py

    django-admin startapp home
   

7. Create the Model (database) for the Task

    from django.db import models
   
    # Create your models here.
   
    class Task(models.Model):
        title = models.CharField(max_length=200)
        complete = models.BooleanField(default=False)
        created = models.DateTimeField(auto_now_add=True)
        expires = models.DateTimeField(auto_now_add=False,blank=True,null=True)
   
        def __str__(self):
            return self.title
   
        @property 
        def is_complete(self):
            return self.complete
   

8. Add the Model in the Admin Panel by adding it to the admin.py file

    from django.contrib import admin
    from .models import Task
   
    # Register your models here.
   
    admin.site.register(Task)
   

9. Make migrations, migrate and Create superuser

    py manage.py makemigrations
    py manage.py migrate
    py manage.py createsuperuser
   

10. Run the Server and go to admin panel.

11. py manage.py runserver 
    goto https://localhost:8000/admin
    

12. login to admin panel and you should see the Tasks under the Home section. Click on Tasks and do CRUD operations.

Congratulations! You've successfully created the database for The Best Todo app ever.

You've completed 2/900 steps of becoming a Django Master

In next Blog, we'll be looking at the V part of MVT architecture

• Brain

• Computer (with Windows in it)

• Python-the programming language, PIP

• Python (optional only for people with passion)

• Access to clean drinking water, edible food, breathable air, Clothes, body, Doctorate in Computer Science, 30Years of Experience as a 19-year-old or (You need to be a Django Master like me).

• Browser in your Computer

• Keyboard

• Keyboard Switches

• Keycaps

• Mouse

• Mouse Buttons

• Mouse Pad

• Electricity

• Connection to Internet

• a Life (optional)

• Power Cord

• LED Lights (very Important)

• Learn the Django Docs byheart 3 times (can't be skipped)

Installing Django

Whenever You are Trying to use the Best Web Framework there is a.k.a. Django. Our Project may depend on some certain lower tier packages to run. and sometimes those packages get updated to higher versions that could cause a project already in deployment to crash. and when we do need to Maintain/add a feature to a project already in Production. we need to know all the packages used and their versions. which makes 1 developer working with more than 1 project a nightmare.

PS: I never Have any problem like this because I am the Django Master.

To resolve this possible future issue, we create Virtual environment to develop our project in, and we will use fancy commands to create a requirements.txt file to let our deployment server know what packages are required to run the project.

You need to type python -m venv <virtualenv name> in console of your choice. and
<virtualenv name>/scripts/activate to activate the Virtual Environment. Below is an example for creating a virtual environment in python named "theusernamedvirtualenvironmentnamegoesinhere"

python -m venv theusernamedvirtualenvironmentnamegoesinhere

theusernamedvirtualenvironmentnamegoesinhere\scripts\activate

You should see this sort of screen after you've activated the virtual environment.

You know when the Virtual environment is activated by looking for a (theusernamedvirtualenvironmentnamegoesinhere) in the beginning of each line.

You need to hit pip freeze after activating the virtual env. and it should return blank line, which means no packages have been installed in our environment(virtual)

if there are some package names being returned by pip freeze, recheck if your virtual environment is active.
once you have made sure your virtual environment is active. you can go ahead and download Django with pip:

pip install django

you should see this screen:

after the download is complete, You can do pip freeze and it should show Django, asgiref, sqlparse, tzdata as the packages. You are ready to start your project now.

the command to create a Django project is:

django-admin startproject yourprojectnamegoesinhere .

the "." at last tells Django that the current directory you're in will be your main project folder. if you don't add that . at the end then your project will be made inside of a folder named "yourprojectnamegoesinhere"

then we need to go to the project's main folder and use the following command

py manage.py runserver

This command will start the server for us and give us the link to the port where the local server is hosted. below is a figure demonstrating it:

Now, we can see the Actual Web Server if we go to Https://localhost:8000/ on our browser of choice. The landing page of empty Django web server Looks like this:

CONGRATULATIONS! You've completed 1/900 Steps of Becoming a Django Master.

In next Blog We'll be creating The Best To-do app anyone's ever seen

Django is a Batteries-included WEB Framework written in Python. Django takes care of the difficult stuff so that you can concentrate on building your web application. But as a Django Master, I don't need Django to take care of the difficult Stuff for me. Django emphasizes reusability of components, also referred to as DRY (Don't Repeat Yourself) and comes with ready-to-use features like login system, database connection and CRUD operations (Create Read Update Delete).

Flow of Data in a Django Server

Request-Response Flow

When a Request is received by the Django server, Some Magic happens, and a Response is Generated. I've devised a Very Detailed Flowchart of the process below:

How does the "Algorithm" work?

As a Django Master, I like to explain the Algorithm as:
When A Request is received by the Server. The Server Looks at the URL that the request is looking for. Then It will look for the Function assigned to handle that URL request. It invokes the Function that will return a Webpage, that gets sent as the Response To that request.

What if the URL doesn't have a function?

Then Obviously an Error Occurs. If you needed to "Know" what happens if URL doesn't have a Function that can handle it. then I suggest you stop reading all blogs from the Django Master. Your monkey brain can't handle the amount of knowledge in upcoming Blogs.

What is the Architecture that Django Uses?

Django Uses MVT architecture.
MVT stands for Model-View-Template

If someone says Django is MVC architecture. Your Response to that request should be, "YOU'RE WRONG AND I HATE YOU!!!"

Below is a Detailed Figure that demonstrates MVT:

If you're not a Django master, you probably Need more explanation on the Figure.

Model: Model is the Database for Django. It is written in Models.py

View: View are the function that will take the data out of database. It is written in Views.py

Template: Template is a Skeleton of the HTML file that wont have any data. It is written in Templates folder

Here is Examples of Model, View and Template's Code:

Models.py:

from django.db import models

class Message(models.Model):
    messageid = models.AutoField(primary_Key = True)
    content = models.CharField()

views.py:

from django.shortcuts import render
from .models import Message

def index(request,message_id):
    template_path = 'templates/index.html'
    msg = Message.objects.get(messageid=message_id)
    context = {
        'message':msg,
    }    
    return render(request,template_path,context)

Templates/index.html

<!Doctype HTML> 
<html>
<head>
    <title> Messages </title>    
</head>
<body>
     <p> The Message is: {{messgage.content}} </p>
</body>
</html>

Thats the Basics of Django. In next blog, We'll start Creating Best TODO Apps the world has ever seen with the Django Master Nischal lamichhane .