Forem: Abdelrahman hassan hamdy

Understanding Layers, Tiers, and N-Tier Architecture in Application Development

Abdelrahman hassan hamdy — Wed, 03 Apr 2024 04:15:01 +0000

In the realm of application development, the architecture of an application significantly impacts its performance, scalability, and ease of maintenance. Developers often talk about "layers" and "tiers" within an application's architecture, terms that are crucial but sometimes misunderstood.

In this article, we will clarify these concepts and delve into the N-tier architecture, focusing on its 3-tier and 4-tier models.

Layers vs. Tiers: What's the Difference?

Although "layers" and "tiers" are often used interchangeably, they refer to different aspects of application architecture:

Layers are virtual separations within an application that organize its different parts, such as the presentation layer (UI), the business logic layer, and the data access layer.

These layers exist within the application's code structure and are a logical way to separate responsibilities and functionalities.

Tiers, on the other hand, refer to the physical distribution of an application's components across different servers or platforms. This physical separation is crucial for an application's scalability, security, and performance. When components are deployed on separate servers and still communicate effectively, they form what is known as a tiered architecture.

Introducing N-Tier Architecture:

N-tier architecture is a scalable and flexible way to structure applications, where "N" represents the number of tiers involved. This architecture divides the application into multiple tiers, each responsible for specific aspects of the application's functionality.

3-Tier Architecture (The Most Common Model):

The 3-tier architecture is a widely adopted model in application development, consisting of the following tiers:

Presentation Tier Tier: This is the user interface (UI) layer, where users interact with the application.
It's built using technologies like HTML, CSS, JavaScript, and frameworks like React or Angular.
Application Tier: The core of the application, this layer contains business rules and logic.
It acts as an intermediary between the presentation and data access layers, ensuring that user inputs are processed and validated.
Technologies used include server-side languages like Java, C#, Python, and frameworks like .NET, Spring, or Django.
Data Tier: This layer is responsible for managing the application's data.
This layer handles communication with databases or other storage mechanisms, providing CRUD (Create, Read, Update, Delete) operations. It uses technologies like JDBC, Entity Framework, or ORM.

4-Tier Architecture:

This additional layer abstracts the business logic's external communication, making the system more modular and enabling services to be reused across different parts of the application or even across different applications.
It's particularly useful in microservices and service-oriented architectures.

In more complex applications, a 4-tier architecture may be employed, which adds an additional tier:

Delivery Tier: This tier focuses on caching and delivering front-end assets to the client, often through a Content Delivery Network (CDN).

The CDN enhances the application's performance and user experience by storing and serving static content from locations closest to the user.

Benefits of N-Tier Architecture:

Scalability: Separating an application into tiers allows for easier scaling of each component independently.
Security: It becomes easier to implement security measures, as each tier can have its own security protocols.
Maintainability: Updates and bug fixes can be carried out more efficiently since changes in one tier do not necessarily affect others.
Efficiency: The development process is streamlined, as developers can focus on specific aspects of the application within each tier.

The Journey to Google: A Tale of Technology and Triumph (real story)

Abdelrahman hassan hamdy — Sun, 17 Mar 2024 23:17:45 +0000

Prologue: A Simple Quest

Imagine embarking on a quest, not through a mystical land, but through the vast expanse of the internet, with a destination as familiar as Google.com. This tale weaves through the intricate web of technology, revealing the marvels behind a journey we take for granted every day. It's a story that begins with a single step - typing https://www.google.com into your browser and pressing Enter.

Chapter 1: The Call to Adventure - DNS Request

Our journey commences in the realm of DNS, the Domain Name System, akin to the ancient maps guiding explorers to undiscovered lands. This system, the internet's phonebook, translates the human-friendly 'www.google.com' into a language of numbers, an IP address, that navigates us through the digital sea. Like sending a raven in medieval times, your computer dispatches a quest to find the IP address, a crucial step without which our journey cannot proceed.

Chapter 2: Crossing the Threshold - TCP/IP

Armed with the IP address, we engage the TCP/IP, the sturdy ship that braves the tumultuous internet sea. This protocol suite is the backbone of our journey, a pact between your browser and Google's distant servers, ensuring your quest is neither lost in stormy waters nor intercepted by pirates. The handshake, a ritual of connection, establishes a secure and reliable path for our voyage.

Chapter 3: Guardians of the Gate - Firewall

En route, we encounter guardians known as Firewalls, imposing fortresses that scrutinize every traveler. These sentinels protect the realms of our computer and Google's servers from unwanted invaders. With the right credentials, our quest continues, shielded from the malevolent forces lurking in the shadows of the internet.

Chapter 4: The Secret Passage - HTTPS/SSL

Our path is enveloped in a cloak of secrecy, thanks to the magic of HTTPS and SSL. These arcane spells encrypt our messages, turning them into undecipherable codes. Only those with the right keys, our browser and the server, can unlock the true message, ensuring our communications remain a secret from prying eyes.

Chapter 5: The Crossroads - Load Balancer

As we near our destination, we encounter a crossroads guarded by a Load Balancer, a wise sage who directs travelers, ensuring no single path becomes overwhelmed. This sage spreads the incoming requests across multiple servers, a testament to Google's foresight in preparing for the deluge of seekers.

Chapter 6: The Gatekeeper - Web Server

Our first encounter in Google's domain is with the Web Server, the gatekeeper who decides which content is worthy to pass through the gates. It retrieves the Google homepage, a treasure trove of information, and presents it before us, a reward for our journey thus far.

Chapter 7: The Inner Sanctum - Application Server

But our quest does not end here. For those who seek knowledge beyond the gates, the Application Server awaits. This powerful ally processes complex queries, delving into the depths of Google's wisdom to bring forth the answers we seek, a testament to the boundless curiosity that drives us.

Chapter 8: The Oracle - Database

In some quests, the Application Server consults the Oracle - the Database. Here lies the collective knowledge of the world, meticulously cataloged and ready to be summoned. This final guardian retrieves the information needed to fulfill our quest, bringing our journey to a successful close.

Epilogue: The Homeward Voyage

As we find ourselves back in the comfort of the familiar, the digital odyssey to Google.com behind us, we stand in awe of the sophisticated tapestry of technologies that facilitated our voyage. From the guiding light of DNS requests to the protective embrace of HTTPS/SSL encryption, and from the judicious guidance of load balancers to the vast archives of knowledge preserved within databases, every phase of our expedition reflects the pinnacle of human creativity and an insatiable quest for understanding.

This journey, seemingly mundane in our daily routines, epitomizes the essence of technological advancement and collaboration. It's a vivid illustration of how far we've journeyed in the digital age, transforming simple acts into grand adventures across the cyber landscape.

Exploring 1-Based Indexing in Programming Languages

Abdelrahman hassan hamdy — Sat, 25 Nov 2023 22:17:23 +0000

Introduction

In the diverse world of programming languages, indexing is a fundamental concept, with most languages adopting 0-based indexing. However, several languages stand out with their choice of 1-based indexing, an intriguing deviation from the norm.

Why 1-Based Indexing?

1-based indexing isn't merely a whimsical choice; it often stems from historical reasons, mathematical convenience, or the preferences of a specific user base. Understanding these languages offers insight into the varied paradigms in programming.

Implications of 1-Based Indexing

The choice of 1-based indexing affects everything from algorithm design to beginner learning curves. It's a testament to the diversity of programming paradigms and their adaptation to different needs.

Language Examples

-------------

1- lua

In Lua, tables (akin to arrays) begin at index 1. This design aligns with Lua's user-friendly philosophy.

local fruits = {"apple", "banana", "cherry"}
print(fruits[1])  -- apple

2 - Fortran

Fortran's arrays start at 1, a choice rooted in its history as a pioneer in scientific computing.

INTEGER :: numbers(5) = [1, 2, 3, 4, 5]
PRINT *, numbers(1)  -- 1

3- matlab

MATLAB's matrix-centric design uses 1-based indexing, ideal for its target audience in engineering and science.

A = [1, 2; 3, 4];
disp(A(1,1))  -- 1

4 - R

R, a language for statistical analysis, uses 1-based indexing, aligning with statistical conventions.

numbers <- c(10, 20, 30)
print(numbers[1])  -- 10

5 - COBOL

In COBOL, often used in business applications, arrays start with index 1, reflecting its business-oriented design.

01 NUMBERS PIC 9(3) OCCURS 5 TIMES.
MOVE 100 TO NUMBERS(1)
DISPLAY NUMBERS(1)

5 - Julia

Julia combines performance and ease of use with 1-based indexing, appealing to scientific computing users.

numbers = [5, 10, 15]
println(numbers[1])  -- 5

6 - Smalltalk

Smalltalk's 1-based arrays reflect its role in pioneering object-oriented programming.

| numbers |
numbers := Array with: 1 with: 2 with: 3.
Transcript show: numbers at: 1.  -- 1

Conclusion

The world of programming languages is rich and varied. The choice between 1-based and 0-based indexing is more than a mere technicality; it reflects deeper philosophical and practical considerations in language design.

Understanding and Implementing Custom Template Tags in Django

Abdelrahman hassan hamdy — Wed, 12 Jul 2023 19:12:51 +0000

When you're developing a web application with Django, the built-in template tags and filters can handle a variety of tasks. However, sometimes you might need more power and flexibility to process the data you're working with, in which case, Django provides the option to write your custom template tags and filters.

Custom Template Tags

Getting Started

Before we delve into creating custom template tags, let's enhance our example application, Myblog, by adding a new Post detail page. This will involve:

Creating a new template for the post detail
Refactoring the byline rendering to remove duplicated code
Adding a link to the Post detail page in the index.html template
Adding a view to fetch and render the new template
Adding a URL mapping to the new view

First, create a new file post-detail.html inside the myblog/templates/blog directory, which will extend the base.html template and override the content block. The content for post-detail.html would look like this:

{% extends "base.html" %}
{% block content %}
<h2>{{ post.title }}</h2>
<div class="row">
    <div class="col">
        {% include "blog/post-byline.html" %}
    </div>
</div>
<div class="row">
    <div class="col">
        {{ post.content|safe }}
    </div>
</div>
{% endblock %}

The post_detail view in views.py would be:

from django.shortcuts import render, get_object_or_404

def post_detail(request, slug):
    post = get_object_or_404(Post, slug=slug)
    return render(request, "blog/post-detail.html", {"post": post})

Next, create another new file post-byline.html in the same directory. The content for post-byline.html would look like this:

{% load blog_extras %}
<small>By {{ post.author|author_details:request.user }} on {{ post.published_at|date:"M, d Y" }}</small>

inside the blog_extras.py

from django import template
from django.contrib.auth import get_user_model
# from django.utils.html import escape
# from django.utils.safestring import mark_safe
from django.utils.html import format_html
from blog.models import Post

user_model = get_user_model()
register = template.Library()


@register.filter
def author_details(author, current_user):
    if not isinstance(author, user_model):
        # return empty string as safe default
        return ""

    if author == current_user:
        return format_html("<strong>me</strong>")

    if author.first_name and author.last_name:
        name = f"{author.first_name} {author.last_name}"
    else:
        name = f"{author.username}"

    if author.email:
        prefix = format_html('<a href="mailto:{}">', author.email)
        suffix = format_html("</a>")
    else:
        prefix = ""
        suffix = ""

    return format_html('{}{}{}', prefix, name, suffix)

The index.html should now look like this:

{% extends "base.html" %}
{% block content %}
    <h2>Blog Posts</h2>
    {% for post in posts %}
    <div class="row">
        <div class="col">
            <h3>{{ post.title }}</h3>
            {% include "blog/post-byline.html" %}
            <p>{{ post.summary }}</p>
            <p>
                ({{ post.content|wordcount }} words)
            <a href="{% url "blog-post-detail" post.slug%}">Read More</a>
            </p>
        </div>
    </div>
    {% endfor %}
{% endblock %}

Finally, add a new URL mapping in urls.py:

from django.urls import path
import blog.views

urlpatterns = [
    # ... other URL patterns ...
    path("post/<slug>/", blog.views.post_detail, name="blog-post-detail"),
]

That's all we learned in the previous article

Creating a Simple Custom Template Tag

A simple custom template tag is built with a Python function that can take any number of arguments, even 0. This function is defined in a Python file inside the templatetags directory of a Django app. Let's create a custom tag for a Bootstrap row:

from django.utils.html import format_html
from django.template import Library

register = Library()

@register.simple_tag
def row(extra_classes=""):
    return format_html('<div class="row {}">', extra_classes)

@register.simple_tag
def endrow():
    return format_html("</div>")

We can now use these tags in our templates:

{% load blog_extras %}
{% block content %}
    <h2>{{ post.title }}</h2>
    {% row %}
        <div class="col">
            {% include "blog/post-byline.html" %}
        </div>
    {% endrow %}
    {% row %}
        <div class="col">
            {{ post.content|safe }}
        </div>
    {% endrow %}
{% endblock %}

Accessing the Template Context in Template Tags

So far, we have only examined how to access variables or values that are explicitly passed to a template tag function. However, with minor modifications to the way the tag is registered, we can enable the tag to access all the context variables that are available in the template in which it's used. This can be handy, for instance, when we need to access the request variable frequently without having to explicitly pass it into the template tag each time.

To provide the template tag access to the context, you need to make two modifications to the template tag function:

When registering, pass takes_context=True to the register.simple_tag decorator.
Add context as the first argument to the template tag function.

Here is an example that demonstrates how we can re-implement the author_details filter as a template tag that doesn't require any arguments:

@register.simple_tag(takes_context=True)
def author_details_tag(context):
    request = context["request"]
    current_user = request.user
    post = context["post"]
    author = post.author

    if author == current_user:
        return format_html("<strong>me</strong>")

    if author.first_name and author.last_name:
        name = f"{author.first_name} {author.last_name}"
    else:
        name = f"{author.username}"

    if author.email:
        prefix = format_html('<a href="mailto:{}">', author.email)
        suffix = format_html("</a>")
    else:
        prefix = ""
        suffix = ""

    return format_html("{}{}{}", prefix, name, suffix)

The usage in the post-byline.html would look like this:

<small>By {% author_details_tag %} on {{ post.published_at|date:"M, d Y" }}</small>

As you can see, we don't need to pass in any variables, although we could pass in arbitrary variables if we wanted. We have access to the template context and can access any variables we need by using it.

While the author_details_tag won't be used in the myblog project, you can still implement it yourself and test it out.

It's important to remember to revert the post-byline.html and blog_extras.py files back to their original state when you're finished. Here's the original version of the author_details filter:

@register.filter
def author_details(author, current_user):
    if not isinstance(author, user_model):
        # return empty string as safe default
        return ""

    if author == current_user:
        return format_html("<strong>me</strong>")

    if author.first_name and author.last_name:
        name = f"{author.first_name} {author.last_name}"
    else:
        name = f"{author.username}"

    if author.email:
        prefix = format_html('<a href="mailto:{}">', author.email)
        suffix = format_html("</a>")
    else:
        prefix = ""
        suffix = ""

    return format_html('{}{}{}', prefix, name, suffix)

<small>By {{ post.author|author_details:request.user }} on {{ post.published_at|date:"M, d Y" }}</small>

The ability to access the template context within custom tags can be very handy. It allows you to use all the context variables available in the original template, simplifying the use of tags and keeping the code clean and organized.

In the next section, we'll explore inclusion tags, and how you can use them to render one template inside another.

Inclusion Tags

Another way to include a template within another is with the include template tag. For example:

{% include "blog/post-byline.html" %}

While easy to implement, this approach has a key limitation: included templates can only access variables already in the including template’s context. Thus, any extra variables must be passed in from the calling view. If you use a template in many places, you may end up repeating the data-loading code in several views.

Inclusion tags address this problem. They let you query for extra data within your template tag function, which can then be used to render a template.

Inclusion tags are registered with the Library.inclusion_tag function. This function requires one argument: the name of the template to render. Unlike simple tags, inclusion tags don’t return a string to render. Instead, they return a context dictionary used to render the template during registration.

A useful feature for a blog site is displaying recent posts. You can create an inclusion tag that fetches the five most recent posts (excluding the current post being viewed) and renders a template.

How to Implement:

Start by creating the template to render - post-list.html in the blog/templates/blog directory:

<h4>{{ title }}</h4>
<ul>
{% for post in posts %}
    <li><a href="{% url "blog-post-detail" post.slug %}">{{ post.title }}</a></li>
{% endfor %}
</ul>

Now, in blog_extras.py, write a recent_posts function that accepts a post argument. Fetch the five most recent Post objects, excluding the Post passed in. Return a dictionary with posts and title keys. Decorate this function with register.inclusion_tag, passing the path to post-list.html:

from blog.models import Post

@register.inclusion_tag("blog/post-list.html")
def recent_posts(post):
    posts = Post.objects.exclude(pk=post.pk)[:5]
    return {"title": "Recent Posts", "posts": posts}

Finally, use this template tag in the post-detail.html template. For instance:

<!-- existing code here -->
{% row %}
    {% col %}
        {% recent_posts post %}
    {% endcol %}
{% endrow %}

Reload a post detail page in your browser, and you should see the "Recent Posts" section, provided you have more than one Post object.

As with a simple tag, you can also pass the context to the inclusion tag function by adding a context argument and adding takes_context=True to the decorator call.

The main benefit of using an inclusion tag is that you can pass in specific information to the inclusion tag that is not found in the regular template tag. In this example, a Post object is passed to the recent_posts template tag, enabling the template tag to access any information in the Post object.

Advanced Template Tags

Simple template tags and inclusion tags cover the majority of use cases for custom template tags. However, Django offers advanced template tags for more customization. These tags consist of two parts:

A parser function: Called when its template tag is encountered in a template. It parses the template tag and extracts variables from the context. It returns a template Node subclass.
The template Node subclass: It has a render method, which is called to return the string to be rendered in the template.

The parser function is registered similarly to other types of tags—by being decorated with @register.tag.

Advanced template tags are useful to:

Capture the content between two tags, perform operations on each node, and choose how they’re output. For instance, you can implement a custom permissions template tag that only outputs the content between them if the current user has the correct permissions.
Set context variables. A template tag could be used to set a value in the template context that is then accessible further on in the template.

While these situations are quite specific, advanced template tags come in handy when the simpler ones don't suffice. If you think you need advanced template tags, check out Django's full documentation on advanced custom template tags.

Leveraging Custom Filters in Django for Effective Data Rendering

Abdelrahman hassan hamdy — Sun, 09 Jul 2023 17:28:37 +0000

In Django, filters allow us to modify variables within the template before they get rendered. This capability can be quite powerful, enabling you to tailor data presentation according to your needs. Django comes with a rich set of built-in filters, but you can also create custom ones if the built-in filters do not meet your requirements.

Built-in Filters in Django

First, let's examine how built-in filters work in Django templates. For example, the lower filter is used to render a value in lowercase. It is applied using the | (pipe) operator inside a rendering block:

{{ value|lower }}

Some filters accept arguments, which can be passed by adding : (colon) after the filter name. For instance, the date filter takes an argument that specifies the output format:

{{ post.published_at|date:"M, d Y" }}

Creating a Django Template with Built-in Filters

Let's see built-in filters in action by creating a Django page that lists all blog posts.

First, update your views.py to fetch all Post objects in the system and send them to the index.html template:

from django.utils import timezone
from blog.models import Post

def index(request):
    posts = Post.objects.filter(published_at__lte=timezone.now())
    return render(request, "blog/index.html", {"posts": posts})

Then, create a simple loop in the index.html template to render each blog post:

{% block content %}
    <h2>Blog Posts</h2>
    {% for post in posts %}
    <div class="row">
        <div class="col">
            <h3>{{ post.title }}</h3>
            <small>By {{ post.author }} on {{ post.published_at|date:"M, d Y" }}</small>
            <p>{{ post.summary }}</p>
            <p>
                ({{ post.content|wordcount }} words)
                <a href="#">Read More</a>
            </p>
        </div>
    </div>
    {% endfor %}
{% endblock %}

In this template, we are using two built-in filters:

The date filter, which formats the publication date.
The wordcount filter, which counts the words in the post's content.

After adding some test data and starting the Django development server, you should see a list of blog posts on your webpage.

Creating Custom Filters in Django

Sometimes, built-in filters might not be enough to satisfy your needs. In such cases, you can create custom filters. These can contain more complex logic, which is often easier to manage than trying to write complex code inside your template.

A custom filter is just a function that takes one or more arguments and returns a string to be rendered in the template.

Let's create a simple custom filter named author_details that will show more details about the author of a post.

First, we create a new Python file, blog_extras.py, in the templatetags directory of our Django app. The function author_details takes a single argument: the author of the post
(which is a django.contrib.auth.models.User object).

from django import template
from django.contrib.auth import get_user_model

register = template.Library()
user_model = get_user_model()

@register.filter
def author_details(author):
    if not isinstance(author, user_model):
        return ""

    if author.first_name and author.last_name:
        return f"{author.first_name} {author.last_name}"
    else:
        return f"{author.username}"

We also use the register.filter decorator to register the function as a custom filter.

After defining the custom filter, we can use it in our template:

{% load blog_extras %}
<small>By {{ post.author|author_details }} on {{ post.published_at|date:"M, d Y" }}</small>

This custom filter will display the author’s first and last name instead of their username, if set.

Custom Filters with Arguments

Filters can also take arguments, as we have seen with the date filter. Let's update our author_details filter to return the string <strong>me</strong> if a post is authored by the currently logged in user.

@register.filter
def author_details(author, current_user):
    from django.utils.html import format_html

    if not isinstance(author, user_model):
        return ""

    if author == current_user:
        return format_html("<strong>me</strong>")

    if author.first_name and author.last_name:
        return f"{author.first_name} {author.last_name}"
    else:
        return f"{author.username}"

We pass the request.user variable to the filter in the template:

<small>By {{ post.author|author_details:request.user }} on {{ post.published_at|date:"M, d Y" }}</small>

Now, if you are logged in as the author of a post, the author name will be replaced by the bolded word "me".

A Post Script on HTML in Template Tags

One of the key features of Django is its template system, designed to allow multiple people with different skills to contribute to a Django project. Those who have HTML, CSS, and other UX skills can work on the templates, while back-end Python developers build the views and models. Generating HTML in a template filter can disrupt this separation of concerns.

Finding where HTML is being generated can become challenging if it’s not in a template but is instead being generated with a template tag. However, doing this can reduce the amount of code and logic in a template, which can arguably make it easier to read. For comparison, here's how our author_details code would look in a template:

<small>By
    {% if post.author == request.user %}
        <strong>me</strong>
    {% else %}
        {% if post.author.email %}
            <a href="mailto:{{ post.author.email }}">
        {% endif %}
            {% if post.author.first_name and post.author.last_name %}
                {{ post.author.first_name }} {{ post.author.last_name }}
            {% else %}
                {{ post.author.username }}
            {% endif %}
        {% if post.author.email %}
            </a>
        {% endif %}
    {% endif %}
    on {{ post.published_at|date:"M, d Y" }}
</small>

The use of {% if post.author.email %} twice, once for the opening and once for the closing <a> tag, can make the code harder to read. As with many things in programming, it depends on your particular situation, personal preference, and organizational needs. Just remember to consider these points when making your decision.

Conclusion

Django filters, both built-in and custom, offer a powerful way to manipulate template variables before rendering. They can simplify your templates and make them more readable. However, remember to use them judiciously, especially when generating HTML in template filters, as it can make it harder to locate where the HTML is being generated and reduce the separation of concerns between the template and the view.

Unraveling Django's Reverse Generic Relationships: An In-Depth Look

Abdelrahman hassan hamdy — Fri, 09 Jun 2023 14:49:30 +0000

When building complex Django applications, you may find yourself needing a way to associate a model with any other model in your project. Django's GenericForeignKey is a powerful feature that provides exactly this kind of flexibility. However, it comes with a caveat – it doesn't support reverse querying. This means that you can't use the ORM to query the model that holds the GenericForeignKey based on the related object. Let's explore this limitation and how to work around it.

The Problem: Reverse Querying on GenericForeignKey

When you attempt to perform a reverse query on a GenericForeignKey, you'll likely run into an error. This could look something like the following:

c = Comment.objects.filter(content_object=p)
# Django throws an error: Field 'content_object' does not generate an automatic reverse relation and therefore cannot be used for reverse querying.

Django raises this error because a GenericForeignKey doesn't create a field on the related object that you can use to trace back the relationship.

The Workaround: Direct Querying Against `content_type` and `object_id`

Although GenericForeignKey can't be queried against directly, there's a workaround. You can filter against the content_type and object_id fields directly. This approach is feasible from within a Django management Python shell:

python3 manage.py shell

Once inside the Python shell, you would execute the following:

from django.contrib.contenttypes.models import ContentType
from blog.models import Post, Comment

post_type = ContentType.objects.get_for_model(Post)
# or
post_type = ContentType.objects.get(app_label="App_name", model="post")

p = Post.objects.first()
c = Comment.objects.filter(content_type=post_type, object_id=p.pk)

This method results in a QuerySet containing the related Comment objects:

<QuerySet [<Comment: Comment object (1)>, <Comment: Comment object (2)>]>

While this solution works, it might be a bit cumbersome if you often need to fetch the related objects.

A Better Way: Using GenericRelation

If you frequently need to query generic related objects of a model, Django's GenericRelation provides a more efficient solution. This feature allows you to set up a reverse generic relationship.

Let's modify the Post model to include a GenericRelation:

from django.contrib.contenttypes.fields import GenericRelation

class Post(models.Model):
    comments = GenericRelation(Comment)

This addition essentially creates a manager (similar to Post.objects) on the Post model, which allows you to directly fetch all related Comment objects:

p = Post.objects.first()
p.comments.all()
# Output: <QuerySet [<Comment: Comment object (1)>, <Comment: Comment object (2)>]>

Furthermore, you can perform operations like add, create, and remove directly on the comments manager:

c1 = p.comments.all()[0]
p.comments.remove(c1)
p.comments.all()
# Output: <QuerySet [<Comment: Comment object (2)>]>

Conclusion

While Django's GenericForeignKey feature is a powerful tool for establishing flexible model relationships, its inability to handle reverse queries can pose a challenge. Fortunately, with a little bit of tweaking and the use of GenericRelation, it's possible to work around this limitation and greatly simplify your queries.

Remember, whenever you make changes to your models, you should create and apply migrations to update your database schema:

python3 manage.py makemigrations
python3 manage.py migrate

Overall, the contenttypes framework in Django provides significant flexibility and convenience when handling generic relationships. The full official Django documentation is a valuable resource for diving deeper into how to use custom queries in GenericRelation fields or how to aggregate generic objects.

When working with generic relationships, keep in mind that although the GenericForeignKey and GenericRelation tools are powerful, they can introduce complexity and potential performance issues in your application if not used correctly. It's essential to evaluate your application's needs and data relationships carefully before opting for a generic relationship design.

Lastly, remember that a robust application requires more than just powerful tools – it requires thoughtful design, an understanding of your application's needs, and the skill to use these tools efficiently and effectively. The use of GenericForeignKey and GenericRelation in Django is just one example of how flexibility can be achieved with a bit of creativity and understanding.

So, don't let limitations stop you from building amazing applications. Explore, learn, and conquer.

Happy coding!

Harnessing Generic Relationships in Django

Abdelrahman hassan hamdy — Fri, 09 Jun 2023 02:26:12 +0000

In the realm of Django development, Generic Relationships provide a flexible way to establish relationships between models. Let's take a look at how they work and why they're so useful.

The Problem with Standard Foreign Keys

To understand the importance of generic relationships, let's consider a blogging application where we want users to be able to leave comments. In this case, we might create a Comment model with a ForeignKey to a Post model, like so:

class Comment(models.Model):
    creator = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE)
    content = models.TextField()
    post = models.ForeignKey(Post, on_delete=models.CASCADE)

But what if we wanted users to comment not only on posts but also on authors? Implementing this with standard ForeignKey fields can be challenging. One approach might be to add another ForeignKey on the Comment model pointing to the User being commented on:

class Comment(models.Model):
    creator = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE)
    content = models.TextField()
    post = models.ForeignKey(Post, on_delete=models.CASCADE, null=True)
    author = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE, null=True)

But this approach comes with problems:

Both the post and author fields can be null, meaning a comment could potentially not be associated with either a post or an author.
Both the post and author fields could be populated simultaneously, meaning a comment could be associated with
both a post and an author, which might not make sense. Extra code would be required to query the correct field when - fetching comments, depending on the context. If we wanted to allow comments on other models in the future, we'd need to add another ForeignKey field to store this relationship.

The Power of Generic Relationships

Enter Generic Relationships. With Django's contenttypes framework, we can establish a relationship with any model using three fields:

A ForeignKey field pointing to a ContentType (usually named content_type).
A PositiveIntegerField storing the primary key of the related object (usually named object_id).
A GenericForeignKey field, a special type of field that looks up the object based on the content_type and object_id fields.

Here's how we could re-implement our Comment model using Generic Relationships:

from django.contrib.contenttypes.fields import GenericForeignKey
from django.contrib.contenttypes.models import ContentType

class Comment(models.Model):
    creator = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE)
    content = models.TextField()
    content_type = models.ForeignKey(ContentType, on_delete=models.CASCADE)
    object_id = models.PositiveIntegerField()
    content_object = GenericForeignKey("content_type", "object_id")

Now, a Comment can be associated with any model simply by assigning the object to content_object. The GenericForeignKey field handles storing the correct ContentType and object ID:

p = Post.objects.first()
u = User.objects.first()
c1 = Comment(creator=u, content="What a great post!", content_object=p)
c1.save()

In [7]: c1.content_object
Out[7]: <Post: An Example Post>

And just as easily, we can add a comment on a User:

c2 = Comment(creator=u, content="I like Django!", content_object=u)
c2.save()

In [10]: c2.content_object
Out[10]: <User: username>

Despite its power, the Generic Relationships framework does have its quirks

for example, in the Django admin interface, you'll need to enter the ID of the related object manually. However, the flexibility and potential for code reuse that it provides makes it an invaluable tool in the Django developer's toolkit.

The contenttypes framework

Abdelrahman hassan hamdy — Tue, 16 Aug 2022 03:46:00 +0000

The main use of the contenttypes framework is to dynamically load models classes based on their name, and subsequently, query objects for that model.

The main model is ContentType, which is importable from django.contrib.contenttypes.model. This works like a normal model whose objects you can query.

If you know the model you want, you can query it using the app name and model name.

Entering Shell Commands:

from django.contrib.contenttypes.models import ContentType

query_post_type = ContentType.objects.get(app_label="bloge", model="post")

query_post_type

The Output : <ContentType: bloge | post>

We could also get a list of all the ContentTypes we have installed, by calling ContentType.objects.all():

ContentType.objects.all()

The Output : 

<QuerySet [<ContentType: admin | log entry>, <ContentType: auth | permission>, <ContentType: auth | group>, <ContentType: auth | user>, <ContentType: contenttypes | content type>, <ContentType: sessions | session>, <ContentType: bloge | post>>

Note that the ContentType object is not the Post model. But, we can retrieve the class with the model_class() method:

query_post_type.model_class()

The Output : bloge.models.Post

It’s also possible to go in reverse, and retrieve the ContentType object from the model. This is done with the ContentType.objects.get_for_model() method.

from blog.models import Post
ContentType.objects.get_for_model(Post)

The OutPut
 <ContentType: bloge | post>

This is useful if you want to know the app_label and model name for a model class.

Once a ContentType object is found, the shortcut method get_objects_for_this_type() will perform a get lookup and retrieve objects for that model class.

query_post_type.get_object_for_this_type(pk=1)

The OutPut : <Post: An Example Post For this section >

Note that this is a shortcut to get on the Post.objects manager instance:

query_post_type.model_class().objects.get(pk=1)

The OutPut : <Post: An Example Post>


query_post_type.get_object_for_this_type(pk=1) == query_post_type.model_class().objects.get(pk=1)

The OutPut: True

Other methods of loading objects (like filter() and all()) are similarly available – remember once you call model_class() it’s just like you’ve imported the model.

This is the extent of what is generally needed to be known to use contenttypes, but if you’re curious about the extra methods that are available, then you can read the contenttypes framework documentation.

Now that we’ve seen how the contenttypes framework can let us dynamically access models.

Another quick example to see the differences between two ways

c1 = ContentType.objects.get_for_model(Post)
c1 
Out[21]: <ContentType: blog | post>
c2 = ContentType.objects.get(app_label="blog", model="post")
c2
Out[23]: <ContentType: blog | post>
c1.get_object_for_this_type()
Out[24]: <Post: hello world#@@ eee>
c2.model_class().objects.first()
Out[25]: <Post: hello world#@@ eee>

How to change the default editor in git for beginners

Abdelrahman hassan hamdy — Wed, 26 May 2021 21:40:47 +0000

When you decide to use a version control system (VCS) into your project using git And start creating the project
folder and writing the first commands,

Creating the first Repository

$ git init

Now we need to add our file into the Repository

$ git add test_code.js

Now the test_code.js file in the Staging area ( Index )

To get the status of our working tree

$ git status

The last step we need to run $ git commit to captures a snapshot of the project's currently staged changes.

$ git commit

Then the default text editor will run you need to write i letter to start typing the commit message and once you have done you need to click on esc button and input :wq to save and quite ,

Here's the problem if you didn’t familiar with the default Vim or nano text editor you need to add this command to use your favourite text editor,
$ git config --global core.editor "Atom"
i'll use Atom as a text editor.

finally Run this command git commit --amend to recover the commit message by input R then press Enter and run the $ git commit again

Good Luck and Happy Learning

Forem: Abdelrahman hassan hamdy

Understanding Layers, Tiers, and N-Tier Architecture in Application Development

Layers vs. Tiers: What's the Difference?

Introducing N-Tier Architecture:

3-Tier Architecture (The Most Common Model):

4-Tier Architecture:

Benefits of N-Tier Architecture:

The Journey to Google: A Tale of Technology and Triumph (real story)

Prologue: A Simple Quest

Chapter 1: The Call to Adventure - DNS Request

Chapter 2: Crossing the Threshold - TCP/IP

Chapter 3: Guardians of the Gate - Firewall

Chapter 4: The Secret Passage - HTTPS/SSL

Chapter 5: The Crossroads - Load Balancer

Chapter 6: The Gatekeeper - Web Server

Chapter 7: The Inner Sanctum - Application Server

Chapter 8: The Oracle - Database

Epilogue: The Homeward Voyage

Exploring 1-Based Indexing in Programming Languages

Introduction

Why 1-Based Indexing?

Implications of 1-Based Indexing

Language Examples

-------------

1- lua

2 - Fortran

3- matlab

4 - R

5 - COBOL

5 - Julia

6 - Smalltalk

Conclusion

Understanding and Implementing Custom Template Tags in Django

Custom Template Tags

Getting Started

Creating a Simple Custom Template Tag

Accessing the Template Context in Template Tags

Inclusion Tags

How to Implement:

Advanced Template Tags

Leveraging Custom Filters in Django for Effective Data Rendering

Built-in Filters in Django

Creating a Django Template with Built-in Filters

Creating Custom Filters in Django

Custom Filters with Arguments

A Post Script on HTML in Template Tags

Conclusion

Unraveling Django's Reverse Generic Relationships: An In-Depth Look

The Problem: Reverse Querying on GenericForeignKey

The Workaround: Direct Querying Against content_type and object_id

A Better Way: Using GenericRelation

Conclusion

Harnessing Generic Relationships in Django

The Problem with Standard Foreign Keys

The Power of Generic Relationships

The contenttypes framework

Entering Shell Commands:

Another quick example to see the differences between two ways

How to change the default editor in git for beginners

Creating the first Repository

To get the status of our working tree

The Workaround: Direct Querying Against `content_type` and `object_id`