DEV Community: Muhammad Atif Iqbal

What is Robocorp?

Muhammad Atif Iqbal — Tue, 07 Oct 2025 13:30:55 +0000

🧠 1. What is Robocorp?

Robocorp is a platform for building, running, and managing software robots — digital workers that automate repetitive computer tasks.

Also Read Robocorp and RPA: The Complete Guide to Open-Source Robotic Process Automation Using Python

It provides:

Developer tools (like Robocorp Lab or VS Code extensions) for creating automation scripts.
A Python-based framework called Robot Framework or RPA Framework.
Cloud orchestration tools (Control Room) to deploy, schedule, and monitor bots.

Think of it like a modern open-source alternative to tools such as UiPath, Blue Prism, or Automation Anywhere — but built on Python and open standards, not proprietary drag-and-drop systems.

⚙️ 2. What is RPA (Robotic Process Automation)?

RPA (Robotic Process Automation) is the technology that allows software "robots" (bots) to mimic human actions on a computer to complete repetitive tasks.

For example:

Reading invoices from emails and entering them into an ERP system.
Copying data between Excel and a web app.
Logging into websites, downloading reports, and sending them by email.

RPA is mainly used in business process automation — finance, HR, healthcare, etc.

🤖 3. What is Robocorp RPA?

Robocorp RPA means using Robocorp’s ecosystem to build and run RPA bots.

In other words:

It’s Robocorp’s implementation of RPA — built with Python and the open-source RPA Framework libraries.

A Robocorp RPA workflow might:

Use Python + RPA Framework to interact with Excel, PDFs, browsers, or APIs.
Be packaged into a “robot” that runs locally or in Robocorp Control Room (cloud).
Be triggered manually, on a schedule, or by API/webhook.

🧩 Example of Robocorp RPA in action:

Let’s say you want a bot to:

Log into Gmail
Download invoice attachments
Extract data from PDF invoices
Enter data into a Google Sheet

You could write this using Robocorp’s RPA Framework:

from RPA.Email.ImapSmtp import ImapSmtp
from RPA.PDF import PDF
from RPA.Google import Sheets

# Simple workflow

Then deploy it in Robocorp’s Control Room to run every morning — fully automated. 🚀

🆚 In short:

Concept	Description	Example
RPA	Automating repetitive tasks using software robots	Any RPA tool like UiPath
Robocorp	A company/platform providing open-source RPA tools built on Python	robocorp.com
Robocorp RPA	RPA implemented using Robocorp’s tools and RPA Framework	Building Python bots for automation

Django formfield_for_foreignkey() function

Muhammad Atif Iqbal — Fri, 03 Oct 2025 13:50:31 +0000

Mastering Django `formfield_for_foreignkey`: Complete Guide with Examples

Django’s admin is one of its most powerful features. Out of the box, it gives you CRUD forms to create, edit, and manage your models. But sometimes, the default dropdowns for ForeignKey fields are too broad — they list all related objects in the database, which may not always be secure, efficient, or user-friendly.

This is where formfield_for_foreignkey comes in.

In this guide, we’ll cover everything you need to know:

✅ What formfield_for_foreignkey is
✅ How Django handles ForeignKey fields by default
✅ Real-world use cases for overriding it
✅ Advanced examples with filtering, permissions, and tenants
✅ Best practices for production apps
✅ FAQs and troubleshooting tips

By the end, you’ll be able to customize your admin dropdowns to be smarter, safer, and tailored to your business rules.

1. What is formfield_for_foreignkey?

In Django Admin, the method formfield_for_foreignkey(self, db_field, request, **kwargs) is a hook method inside ModelAdmin. It allows you to customize the queryset for ForeignKey dropdown fields in the admin form.

By default, Django lists all related objects in the dropdown. But with this hook, you can:

Filter objects (e.g., only active ones)
Restrict by logged-in user
Sort objects for usability
Enforce multi-tenant separation
Apply role-based visibility rules

Method signature:

def formfield_for_foreignkey(self, db_field, request, **kwargs):
    # custom logic
    return super().formfield_for_foreignkey(db_field, request, **kwargs)

2. How Django Handles ForeignKey by Default

Consider this example:

class Author(models.Model):
    name = models.CharField(max_length=100)

class Book(models.Model):
    title = models.CharField(max_length=200)
    author = models.ForeignKey(Author, on_delete=models.CASCADE)

In Django Admin, when creating a Book, the author dropdown will list all authors in the database.

That’s fine for small projects, but:

It can clutter the UI when there are thousands of authors.
It may expose data users shouldn’t see (e.g., other tenants’ data).
It can confuse staff who only need a subset.

This is the default behavior — and exactly where formfield_for_foreignkey helps.

3. Real-World Use Cases

Example 1: Filter by Logged-In User

@admin.register(Book)
class BookAdmin(admin.ModelAdmin):
    def formfield_for_foreignkey(self, db_field, request, **kwargs):
        if db_field.name == "author":
            kwargs["queryset"] = Author.objects.filter(created_by=request.user)
        return super().formfield_for_foreignkey(db_field, request, **kwargs)

✅ Only authors created by the logged-in user appear in the dropdown.

Example 2: Show Only Active Records

def formfield_for_foreignkey(self, db_field, request, **kwargs):
    if db_field.name == "author":
        kwargs["queryset"] = Author.objects.filter(is_active=True)
    return super().formfield_for_foreignkey(db_field, request, **kwargs)

✅ Inactive authors are hidden.

Example 3: Sort Dropdown Alphabetically

def formfield_for_foreignkey(self, db_field, request, **kwargs):
    if db_field.name == "author":
        kwargs["queryset"] = Author.objects.all().order_by("name")
    return super().formfield_for_foreignkey(db_field, request, **kwargs)

✅ Users see a clean, ordered dropdown.

Example 4: Restrict by Permissions

def formfield_for_foreignkey(self, db_field, request, **kwargs):
    if db_field.name == "author":
        if request.user.has_perm("app.view_all_authors"):
            kwargs["queryset"] = Author.objects.all()
        else:
            kwargs["queryset"] = Author.objects.filter(created_by=request.user)
    return super().formfield_for_foreignkey(db_field, request, **kwargs)

✅ Superusers/managers see all authors.
✅ Staff see only their own.

Example 5: Multi-Tenant Filtering

def formfield_for_foreignkey(self, db_field, request, **kwargs):
    if db_field.name == "customer":
        kwargs["queryset"] = Customer.objects.filter(tenant=request.user.tenant)
    return super().formfield_for_foreignkey(db_field, request, **kwargs)

✅ Each tenant only sees their own customers.

4. When to Use It?

You should override formfield_for_foreignkey when:

You want to limit foreign key options based on logged-in user.
You need to hide irrelevant or sensitive records.
You want to improve usability by sorting or filtering.
You’re working with a multi-tenant app.

5. Best Practices

✅ Always call super() at the end.
✅ Keep queries efficient — avoid heavy joins here.
✅ Apply consistent filtering across forms and lists (get_queryset).
✅ Test with multiple roles (staff, superuser).
✅ Document your filtering logic — future devs will thank you.

6. Common Mistakes

❌ Forgetting to return super() → breaks form rendering.
❌ Overly complex queries → slows down admin.
❌ Inconsistent logic with get_queryset → users see mismatched data.

7. FAQs

Q: Can I filter dropdowns differently for add vs. change forms?
👉 Yes, you can check request.resolver_match or request.path to see the context.

Q: Can I use it for ManyToMany fields?
👉 Use formfield_for_manytomany instead.

Q: Is this the only way to filter foreign keys?
👉 No — you can also use custom ModelForms, but this method is the most admin-friendly.

8. Final Thoughts

Django’s formfield_for_foreignkey is more than just a customization hook — it’s a security and usability tool. By mastering it, you can:

Keep admin dropdowns clean and focused.
Enforce tenant and role-based restrictions.
Prevent accidental data leaks.

'formfield_for_foreignkey()' with Django Permissions: Fine-Grained Control in Admin

Muhammad Atif Iqbal — Fri, 03 Oct 2025 12:56:31 +0000

formfield_for_foreignkey()' with Django## Mastering formfield_for_foreignkey with Django Permissions: Fine-Grained Control in Admin

Django’s admin is famous for giving developers a fully functional interface out of the box. But real-world apps often need fine-grained access control — different users should see different subsets of related objects.

You may already know about formfield_for_foreignkey, a hook that lets you filter ForeignKey dropdowns in Django Admin. But here’s where it gets really powerful: combine it with Django’s built-in permissions and roles to create a role-aware and secure admin.

In this article, we’ll explore:

✅ Why combine formfield_for_foreignkey with permissions
✅ How to restrict dropdowns using has_perm()
✅ Using groups and roles for finer control
✅ Handling sensitive data with custom rules
✅ Multi-tenant use cases
✅ Best practices

What is formfield_for_foreignkey?

Django provides this method inside ModelAdmin classes to customize the queryset for a ForeignKey dropdown. By default, it lists all related objects in the database. But with formfield_for_foreignkey, you can filter, sort, or restrict that list.

Signature:

def formfield_for_foreignkey(self, db_field, request, **kwargs):
    # custom logic here
    return super().formfield_for_foreignkey(db_field, request, **kwargs)

Why Combine with Permissions?

While formfield_for_foreignkey controls what objects appear, Django’s permission system controls who can see what. Combining them means:

Different roles (staff, manager, superuser) see different dropdown options
Sensitive objects can be hidden unless a user has explicit permission
Multi-tenant applications prevent cross-tenant data leaks

Example 1: Restrict by Permission

Suppose you have Author and Book models. Normally, all authors would appear in the dropdown. But maybe only staff with the app.view_all_authors permission should see everyone. Others should see only their own.

from django.contrib import admin
from .models import Author, Book

@admin.register(Book)
class BookAdmin(admin.ModelAdmin):
    def formfield_for_foreignkey(self, db_field, request, **kwargs):
        if db_field.name == "author":
            if request.user.has_perm("app.view_all_authors"):
                kwargs["queryset"] = Author.objects.all()
            else:
                kwargs["queryset"] = Author.objects.filter(created_by=request.user)
        return super().formfield_for_foreignkey(db_field, request, **kwargs)

✅ Superusers or staff with the permission see all authors.
✅ Other users see only the authors they created.

Example 2: Role-Based Dropdown Filtering

If you’re using Django groups or a role field on your User model, you can scope choices based on role.

def formfield_for_foreignkey(self, db_field, request, **kwargs):
    if db_field.name == "author":
        if request.user.groups.filter(name="Managers").exists():
            # Managers see all active authors
            kwargs["queryset"] = Author.objects.filter(is_active=True)
        else:
            # Regular staff only see their own active authors
            kwargs["queryset"] = Author.objects.filter(
                created_by=request.user, is_active=True
            )
    return super().formfield_for_foreignkey(db_field, request, **kwargs)

✅ Managers have broader visibility.
✅ Staff stay scoped to their own data.

Example 3: Handling Sensitive Data

Sometimes you want to hide sensitive objects unless the user has explicit permission.

def formfield_for_foreignkey(self, db_field, request, **kwargs):
    if db_field.name == "project":
        qs = Project.objects.filter(is_active=True)

        if not request.user.has_perm("app.can_assign_sensitive_projects"):
            qs = qs.exclude(is_sensitive=True)

        kwargs["queryset"] = qs
    return super().formfield_for_foreignkey(db_field, request, **kwargs)

✅ Sensitive projects don’t even appear in the dropdown unless allowed.

Example 4: Multi-Tenant Use Case

In SaaS apps with multiple tenants, you can combine tenant ownership with permissions.

def formfield_for_foreignkey(self, db_field, request, **kwargs):
    if db_field.name == "customer":
        qs = Customer.objects.filter(tenant=request.user.tenant)

        if not request.user.has_perm("app.view_inactive_customers"):
            qs = qs.filter(is_active=True)

        kwargs["queryset"] = qs
    return super().formfield_for_foreignkey(db_field, request, **kwargs)

✅ Users only see customers from their tenant.
✅ Optional permission controls visibility of inactive customers.

Best Practices

Always call super() at the end to retain Django’s defaults.
Keep queries efficient — avoid heavy joins inside this method.
Test with multiple roles (staff, manager, superuser) to avoid hidden bugs.
Stay consistent — if you filter dropdowns here, apply the same logic in get_queryset() for list views.

Final Thoughts

formfield_for_foreignkey gives you object-level filtering power, while Django’s permission system gives you user-level control. Together, they create an admin that’s secure, role-aware, and tenant-safe.

Whether you’re managing sensitive data, building a SaaS app, or just keeping the admin clean for staff, mastering this combination will make your Django admin much more robust.

👉 With these examples, you can now:

Use permissions to decide who sees what in dropdowns.
Implement role-based logic with groups.
Keep your admin secure in multi-tenant and sensitive-data scenarios.

How to Restrict ForeignKey Choices in Django

Muhammad Atif Iqbal — Fri, 03 Oct 2025 11:22:06 +0000

Introduction

If you’ve ever built an application with Django Admin, you’ve probably used dropdowns for related models. These dropdowns appear whenever you have a ForeignKey field.

Read this article aslo How to Restrict ForeignKey Choices in Django

But here’s the problem:
By default, Django Admin will show all related objects in that dropdown.

What if you only want to show the objects created by the logged-in user?
Or maybe you want staff users to only see certain options?
Or perhaps you need to filter choices based on business logic (like only “active” records)?

If you landed here by searching things like:

“Django admin limit dropdown choices”
“How to restrict ForeignKey options per user in Django”
“Django admin filter related objects dynamically”
“Restrict choices in Django admin form”
“How to show limited foreign key options in Django”

👉 Then this article is exactly for you.

The solution lies in a powerful Django Admin method:
formfield_for_foreignkey(self, db_field, request, **kwargs)

In this article, we’ll explore:

Why Django shows all ForeignKey objects by default
How to filter dropdown choices in the admin
Step-by-step examples with code
Alternative approaches (querysets, limit_choices_to)
Best practices for performance & maintainability
Common pitfalls & FAQs

By the end, you’ll know exactly how to control your admin dropdowns like a pro.

Why Does Django Show All ForeignKey Choices by Default?

When Django sees a ForeignKey in your model, it automatically renders a dropdown in the Admin. For example:

from django.db import models

class Author(models.Model):
    name = models.CharField(max_length=100)

class Book(models.Model):
    title = models.CharField(max_length=200)
    author = models.ForeignKey(Author, on_delete=models.CASCADE)

In the Book Admin form, Django will render a dropdown for author.

But by default:

It will show all authors from the database.
Even if you only want to allow some of them.

That’s fine for small projects, but in real-world apps, you often need restrictions.

When Do You Need to Restrict ForeignKey Choices?

Here are some common use cases where you might want to filter ForeignKey dropdowns in Django Admin:

User-specific data

Example: Only show Projects created by the logged-in user.
Useful in multi-tenant apps.

Role-based filtering

Example: Staff can only assign orders to employees in their department.

Status-based filtering

Example: Only show “active” categories, not archived ones.

Security restrictions

Example: Prevent staff users from accessing other users’ data.

Performance reasons

If you have thousands of related objects, filtering avoids slow dropdowns.

The Django Way: Using `formfield_for_foreignkey`

Django gives us a built-in method for this exact problem:
formfield_for_foreignkey(self, db_field, request, **kwargs)

This method is part of the ModelAdmin class and runs whenever Django builds a form field for a ForeignKey.

Method Signature

def formfield_for_foreignkey(self, db_field, request, **kwargs):
    # your logic here
    return super().formfield_for_foreignkey(db_field, request, **kwargs)

db_field → the field object (so you can check if it’s the field you want to customize).
request → the current HTTP request (so you can check the logged-in user).
kwargs → extra options passed to the form field.

Example 1: Restrict Choices to Logged-in User

Let’s say each Book belongs to an Author, and you want a user to only select themselves as the author.

from django.contrib import admin
from .models import Book, Author

class BookAdmin(admin.ModelAdmin):
    def formfield_for_foreignkey(self, db_field, request, **kwargs):
        if db_field.name == "author":
            kwargs["queryset"] = Author.objects.filter(user=request.user)
        return super().formfield_for_foreignkey(db_field, request, **kwargs)

admin.site.register(Book, BookAdmin)

✔ Now, the dropdown for author will only show authors tied to the logged-in user.

Example 2: Restrict Choices Based on User Role

Let’s say staff users should only see authors in their department.

class BookAdmin(admin.ModelAdmin):
    def formfield_for_foreignkey(self, db_field, request, **kwargs):
        if db_field.name == "author" and not request.user.is_superuser:
            kwargs["queryset"] = Author.objects.filter(department=request.user.department)
        return super().formfield_for_foreignkey(db_field, request, **kwargs)

✔ Superusers see all authors, staff see filtered ones.

Example 3: Show Only Active Records

class BookAdmin(admin.ModelAdmin):
    def formfield_for_foreignkey(self, db_field, request, **kwargs):
        if db_field.name == "author":
            kwargs["queryset"] = Author.objects.filter(is_active=True)
        return super().formfield_for_foreignkey(db_field, request, **kwargs)

✔ Only active authors appear in the dropdown.

Alternative Approaches

Sometimes you don’t need formfield_for_foreignkey. Here are other options:

1. Using `limit_choices_to` in the Model

class Book(models.Model):
    author = models.ForeignKey(
        Author, 
        on_delete=models.CASCADE,
        limit_choices_to={'is_active': True}
    )

⚠️ Downside: This is static — you can’t use the logged-in user or request context.

2. Overriding the Form Class

You can also customize choices in the form itself:

from django import forms
from .models import Book, Author

class BookForm(forms.ModelForm):
    class Meta:
        model = Book
        fields = "__all__"

    def __init__(self, *args, **kwargs):
        user = kwargs.pop('request').user
        super().__init__(*args, **kwargs)
        self.fields['author'].queryset = Author.objects.filter(user=user)

Then plug the form into your admin:

class BookAdmin(admin.ModelAdmin):
    form = BookForm

Best Practices

✅ Use formfield_for_foreignkey if you need request-aware filtering.
✅ Use limit_choices_to for static filters.
✅ Cache querysets if you expect heavy load.
✅ Always allow superusers full access.

Common Pitfalls

Forgetting super()
Always call the parent method, otherwise you may break Django’s defaults.
Filtering too aggressively
If you filter incorrectly, you might prevent staff from editing old data.
Performance issues
Large querysets in dropdowns can slow down admin forms — add filters wisely.

FAQs

❓ Can I restrict ForeignKey dropdowns outside the admin?

Yes — in custom forms, override the __init__ method and filter querysets.

❓ Can I hide the dropdown completely?

Yes — you can set readonly_fields or replace the field with a custom widget.

❓ What if I want autocomplete instead of dropdown?

Use autocomplete_fields in your ModelAdmin. It works well with large datasets.

Conclusion

Restricting ForeignKey choices in Django Admin is a common real-world need.
And Django makes it easy with the formfield_for_foreignkey method.

So whether you searched for:

“How to filter related objects in Django admin form”
“Django admin restrict choices dynamically per user”
“Limit ForeignKey dropdown in Django”

👉 This guide gives you the complete solution.

By overriding formfield_for_foreignkey, you can:

Filter dropdowns per user
Apply role-based restrictions
Improve performance
Keep your admin secure

Read this article aslo How to Restrict ForeignKey Choices in Django

`formfield_for_foreignkey()` in Django Admin: A Complete Guide

Muhammad Atif Iqbal — Fri, 03 Oct 2025 10:22:25 +0000

Mastering `formfield_for_foreignkey` in Django Admin: A Complete Guide

Django’s admin is one of its most powerful features. Out of the box, it gives you forms to create, edit, and manage your models. But sometimes, the default dropdowns for ForeignKey fields are too permissive — they show all related objects in the database.

What if you want to restrict the choices a user can see, based on who is logged in, or some business logic?

That’s where formfield_for_foreignkey comes in.

Read this aticle also formfield_for_foreignkey in Django

In this article, we’ll dive into:

✅ What is formfield_for_foreignkey?
✅ How Django handles ForeignKey fields by default
✅ Real-world examples of overriding formfield_for_foreignkey
✅ When and why you should use it
✅ Best practices

🔎 What is `formfield_for_foreignkey` in Django Admin?

In Django Admin, the method formfield_for_foreignkey(self, db_field, request, **kwargs) is a hook method that lets you customize the queryset for ForeignKey dropdown fields in the admin form.

By default, Django will show all objects of the related model.
With this method, you can filter, sort, or limit the available options.

Method signature:

def formfield_for_foreignkey(self, db_field, request, **kwargs):
    # custom logic
    return super().formfield_for_foreignkey(db_field, request, **kwargs)

🛠 How Django Handles ForeignKey by Default

Imagine we have two models:

class Author(models.Model):
    name = models.CharField(max_length=100)

class Book(models.Model):
    title = models.CharField(max_length=200)
    author = models.ForeignKey(Author, on_delete=models.CASCADE)

In the Django Admin, when creating a Book, the author dropdown will list all authors in the database.
This is the default behavior.

But what if you only want staff users to see authors they created? That’s where you override formfield_for_foreignkey.

🚀 Example 1: Filter ForeignKey Choices by Logged-in User

from django.contrib import admin
from .models import Book, Author

@admin.register(Book)
class BookAdmin(admin.ModelAdmin):

    def formfield_for_foreignkey(self, db_field, request, **kwargs):
        if db_field.name == "author":
            # Only show authors created by the logged-in user
            kwargs["queryset"] = Author.objects.filter(created_by=request.user)
        return super().formfield_for_foreignkey(db_field, request, **kwargs)

✅ Now, when a staff user opens the Book form, the author dropdown only lists the authors they created.
Superusers will still see everything.

🚀 Example 2: Show Only Active Related Objects

Sometimes you want to show only active records.

def formfield_for_foreignkey(self, db_field, request, **kwargs):
    if db_field.name == "author":
        kwargs["queryset"] = Author.objects.filter(is_active=True)
    return super().formfield_for_foreignkey(db_field, request, **kwargs)

✅ Now, inactive authors won’t appear in the dropdown.

🚀 Example 3: Sort the Dropdown Options

You can also order the queryset to make the dropdown more user-friendly:

def formfield_for_foreignkey(self, db_field, request, **kwargs):
    if db_field.name == "author":
        kwargs["queryset"] = Author.objects.all().order_by("name")
    return super().formfield_for_foreignkey(db_field, request, **kwargs)

🔑 When Should You Use `formfield_for_foreignkey`?

You should override this method when:

You want to restrict foreign key options based on the logged-in user.
You need to hide inactive or irrelevant related objects.
You want to improve usability by sorting or limiting dropdown choices.
You are working in a multi-tenant application where users should not see each other’s data.

⚡ Best Practices

Always call super() at the end so Django can apply its defaults.
Be careful with queries — don’t run expensive queries inside this method.
Test both staff and superuser accounts to ensure permissions work as expected.
Keep the logic simple — if the filtering is very complex, consider using custom forms instead.

🎯 Final Thoughts

The formfield_for_foreignkey method is one of the most useful hooks in Django Admin. It gives you control over what appears in your ForeignKey dropdowns, making your admin interface safer, more user-friendly, and tenant-aware.

Whether you’re building a small project or a large SaaS app, mastering this hook will save you a lot of time and prevent accidental data leaks.

✅ With this article, you can now:

Explain what formfield_for_foreignkey is.
Customize dropdowns for different use cases.
Improve your Django admin forms for better usability and security.

Read this aticle also formfield_for_foreignkey in Django

Demystifying db_field in Django Admin

Muhammad Atif Iqbal — Thu, 02 Oct 2025 12:55:53 +0000

When working with Django Admin, you’ll often need to customize how fields appear in your forms. Django provides hooks such as formfield_for_foreignkey, formfield_for_choice_field, and formfield_for_dbfield — all of which receive an argument called db_field.

If you’ve ever wondered what exactly db_field is and how you can use it, this article is for you.

For complete article please visit db_field in Django Admin

What is `db_field`?

In short, db_field is the model field object being processed when Django builds the admin form.

When you define a model:

from django.db import models

class Author(models.Model):
    name = models.CharField(max_length=100)

class Book(models.Model):
    title = models.CharField(max_length=200)
    author = models.ForeignKey(Author, on_delete=models.CASCADE)

Django Admin inspects each field (title, author, etc.) when rendering the form. At that point, it passes the actual field instance (a CharField or ForeignKey) to your override methods as db_field.

So:

For Book.title → db_field will be a CharField instance.
For Book.author → db_field will be a ForeignKey instance.

Where is `db_field` Used?

The db_field argument appears in several admin customization methods:

formfield_for_foreignkey(self, db_field, request, **kwargs)
→ Lets you change how ForeignKey fields are displayed.
formfield_for_choice_field(self, db_field, request, **kwargs)
→ Lets you modify dropdowns created from choices.
formfield_for_dbfield(self, db_field, request, **kwargs)
→ A generic hook for any field type.

Example 1 — Filtering a ForeignKey

Imagine you want to limit which authors appear in the dropdown when creating a book.

from django.contrib import admin

class BookAdmin(admin.ModelAdmin):
    def formfield_for_foreignkey(self, db_field, request, **kwargs):
        # Only customize the "author" field
        if db_field.name == "author":
            kwargs["queryset"] = Author.objects.filter(name__startswith="A")
        return super().formfield_for_foreignkey(db_field, request, **kwargs)

🔎 What’s happening?

Django passes the Book.author field as db_field.
We check db_field.name == "author".
Then we override its queryset to only show authors whose names start with “A”.

Example 2 — Customizing Choices

Suppose you have a field with predefined choices:

class Book(models.Model):
    GENRE_CHOICES = [
        ("fiction", "Fiction"),
        ("nonfiction", "Non-Fiction"),
        ("poetry", "Poetry"),
    ]
    title = models.CharField(max_length=200)
    genre = models.CharField(max_length=20, choices=GENRE_CHOICES)

You can alter how these choices appear in admin:

class BookAdmin(admin.ModelAdmin):
    def formfield_for_choice_field(self, db_field, request, **kwargs):
        if db_field.name == "genre":
            # Reorder or filter choices
            kwargs["choices"] = [
                ("fiction", "Fiction"),
                ("poetry", "Poetry"),
            ]
        return super().formfield_for_choice_field(db_field, request, **kwargs)

Example 3 — Catch-All with `formfield_for_dbfield`

If you want to apply a rule to all fields, use formfield_for_dbfield:

class BookAdmin(admin.ModelAdmin):
    def formfield_for_dbfield(self, db_field, request, **kwargs):
        # Example: add placeholder text to all CharFields
        if isinstance(db_field, models.CharField):
            kwargs["widget"].attrs["placeholder"] = f"Enter {db_field.verbose_name}"
        return super().formfield_for_dbfield(db_field, request, **kwargs)

Here, every CharField in the model gets a placeholder in its admin input box.

Why is `db_field` Useful?

🎯 Granular Control — target individual fields like author or genre.
👥 User-Specific Filtering — restrict dropdowns per user role.
🛠 Custom Widgets — attach custom widgets or attributes.
🧹 Centralized Logic — all customization stays inside ModelAdmin.

Key Takeaways

db_field is the actual field object from your model.
Django sends it to hooks so you can inspect the field and modify its admin form behavior.
Use:
- formfield_for_foreignkey → control ForeignKey dropdowns.
- formfield_for_choice_field → control choices.
- formfield_for_dbfield → catch-all for any field type.

✅ By leveraging db_field, you can transform the Django Admin from a basic CRUD tool into a finely tuned interface that enforces business rules and improves usability.

What is threading in Python?

Muhammad Atif Iqbal — Mon, 15 Sep 2025 13:49:53 +0000

🔹 What is threading in Python?

Threading means running multiple threads of execution within the same process.
A thread is the smallest unit of a program that can run independently.
In Python, threads are often used for tasks like:
- Handling multiple user requests in a web server.
- Running background tasks (like sending emails, logging, or processing data).
- Improving responsiveness (so the program doesn’t “freeze” while waiting for something).

👉 Example:

import threading
import time

def worker(name):
    print(f"{name} started")
    time.sleep(2)
    print(f"{name} finished")

# Create 2 threads
t1 = threading.Thread(target=worker, args=("Thread-1",))
t2 = threading.Thread(target=worker, args=("Thread-2",))

t1.start()
t2.start()

This runs two “workers” at the same time (interleaved).

🔹 Why use threading in Django?

Django (and many web servers like Gunicorn or Uvicorn) may serve multiple users at once.
Each request may be handled by a different thread.
If you need some data specific to a request/thread (like which website/domain is being used), you can store it in thread-local storage so that it doesn’t get mixed up with another request.

🔹 What is `_thread_local`?

_thread_local = threading.local()

threading.local() creates a thread-local storage object.
That means each thread can store its own attributes without interfering with other threads.
_thread_local is just a variable name (the underscore _ is a Python convention meaning “this is private, internal use”).

👉 Example:

import threading

local_data = threading.local()

def worker(name):
    local_data.value = name
    print(f"In {name}, local_data.value = {local_data.value}")

t1 = threading.Thread(target=worker, args=("Thread-1",))
t2 = threading.Thread(target=worker, args=("Thread-2",))

t1.start()
t2.start()

Each thread has its own local_data.value → no conflict.

✅ Summary in plain words:

Threading = running multiple requests at once.
threading.local() = keeps request-specific data separate.
_thread_local.current_website = acts like a per-request global variable.
Underscore _ = naming convention meaning “internal use only”.

What is a Decorator in Python, Django and FastAPI?

Muhammad Atif Iqbal — Thu, 04 Sep 2025 12:02:51 +0000

🔹 Decorators in Python, Django and FastAPI in details with examples

In Python, a decorator is a function that wraps another function or class to modify or extend its behavior without changing its code directly.

Think of it like:

“A decorator takes a function/class as input → adds some extra functionality → and returns a new function/class.”

🔹 Example 1 – Simple function decorator

def my_decorator(func):
    def wrapper():
        print("Before function runs")
        func()
        print("After function runs")
    return wrapper

@my_decorator   # same as: hello = my_decorator(hello)
def hello():
    print("Hello, World!")

hello()

Output:

Before function runs
Hello, World!
After function runs

Here:

@my_decorator wraps the hello() function.
When you call hello(), actually wrapper() runs.

🔹 Example 2 – Decorator with arguments

def repeat(n):
    def decorator(func):
        def wrapper(*args, **kwargs):
            for _ in range(n):
                func(*args, **kwargs)
        return wrapper
    return decorator

@repeat(3)   # repeat hello 3 times
def hello(name):
    print(f"Hello {name}!")

hello("Atif")

Output:

Hello Atif!
Hello Atif!
Hello Atif!

🔹 Example 3 – Django decorator

In Django, you’ve seen things like:

from django.contrib.auth.decorators import login_required

@login_required
def my_view(request):
    ...

Here @login_required ensures that only logged-in users can access that view.

🔹 Example 4 – Class decorator (Django admin)

In your admin file, you saw:

@admin.register(Payment)
class PaymentAdmin(admin.ModelAdmin):
    ...

This is a class decorator.
It tells Django: “Register the Payment model in the admin, using this custom admin class.”

Equivalent without decorator:

class PaymentAdmin(admin.ModelAdmin):
    ...

admin.site.register(Payment, PaymentAdmin)

🔹 Example 5 – FastAPI decorator

In FastAPI, routes are defined with decorators:

from fastapi import FastAPI

app = FastAPI()

@app.get("/hello")
def say_hello():
    return {"msg": "Hello World"}

Here @app.get("/hello") is a decorator that says: “When someone sends a GET request to /hello, call this function.”

✅ Summary for decorators:

Decorators = wrappers that extend/modify behavior of functions/classes.
They’re widely used in Django (admin, views, permissions) and FastAPI (routes, middlewares).

how to write your own decorator step by step

Let’s build your own decorators step by step.
We’ll start from very basic → then add arguments → then apply in Django-like use cases.

🛠 Step 1: Basic decorator

def simple_decorator(func):
    def wrapper():
        print("👉 Before the function")
        func()
        print("👉 After the function")
    return wrapper

@simple_decorator
def say_hello():
    print("Hello Atif!")

say_hello()

Output:

👉 Before the function
Hello Atif!
👉 After the function

📌 Here:

@simple_decorator is applied to say_hello.
When you call say_hello(), Python actually runs wrapper().

🛠 Step 2: Decorator for any function with arguments

def log_args(func):
    def wrapper(*args, **kwargs):
        print(f"Function {func.__name__} called with args={args}, kwargs={kwargs}")
        return func(*args, **kwargs)   # run the real function
    return wrapper

@log_args
def add(a, b):
    return a + b

print(add(3, 5))

Output:

Function add called with args=(3, 5), kwargs={}
8

🛠 Step 3: Decorator with arguments

Sometimes you want to pass options to your decorator itself.

def repeat(n):
    def decorator(func):
        def wrapper(*args, **kwargs):
            for i in range(n):
                print(f"Run {i+1} of {n}")
                func(*args, **kwargs)
        return wrapper
    return decorator

@repeat(3)   # repeat the function 3 times
def greet(name):
    print(f"Hello {name}")

greet("Atif")

Output:

Run 1 of 3
Hello Atif
Run 2 of 3
Hello Atif
Run 3 of 3
Hello Atif

Decorator in Django

🛠 A Django-like decorator

Let’s make our own login_required style decorator:

def my_login_required(func):
    def wrapper(request, *args, **kwargs):
        if not getattr(request, "user", None):   # check if request has a user
            return "❌ User not logged in!"
        return func(request, *args, **kwargs)
    return wrapper

# fake request objects
class Request:
    def __init__(self, user=None):
        self.user = user

@my_login_required
def dashboard(request):
    return f"Welcome {request.user}!"

print(dashboard(Request()))        # no user
print(dashboard(Request("Atif")))  # with user

Output:

❌ User not logged in!
Welcome Atif!

🛠 Using class decorator (like Django Admin)

def register_model(model_name):
    def decorator(admin_class):
        print(f"✅ Registered {model_name} with admin class {admin_class.__name__}")
        return admin_class
    return decorator

@register_model("Payment")
class PaymentAdmin:
    pass

Output:

✅ Registered Payment with admin class PaymentAdmin

📌 This is exactly how @admin.register(Model) works internally.

✅ Summary for Django Decorators:

A decorator is a function that wraps another function/class.
@decorator_name is just shorthand for function = decorator_name(function).
They’re useful for authentication checks, logging, caching, registering routes/admins, etc.

decorators in FastAPI.

They work the same as Python decorators, but in FastAPI they’re often used for middleware-like behavior (before/after running your endpoint).

🛠 Example 1: Simple logging decorator

from fastapi import FastAPI

app = FastAPI()

# Custom decorator
def log_request(func):
    async def wrapper(*args, **kwargs):
        print(f"👉 Calling endpoint: {func.__name__}")
        result = await func(*args, **kwargs)
        print(f"✅ Finished endpoint: {func.__name__}")
        return result
    return wrapper

@app.get("/hello")
@log_request
async def say_hello():
    return {"message": "Hello Atif!"}

When you visit /hello:

👉 Calling endpoint: say_hello
✅ Finished endpoint: say_hello

🛠 Example 2: Decorator to check API Key

from fastapi import FastAPI, Request, HTTPException

app = FastAPI()

def require_api_key(func):
    async def wrapper(request: Request, *args, **kwargs):
        api_key = request.headers.get("X-API-Key")
        if api_key != "secret123":
            raise HTTPException(status_code=403, detail="Invalid API Key")
        return await func(request, *args, **kwargs)
    return wrapper

@app.get("/secure")
@require_api_key
async def secure_endpoint(request: Request):
    return {"message": "You are authorized!"}

🔑 If you call /secure without X-API-Key: secret123, you’ll get:

{"detail": "Invalid API Key"}

🛠 Example 3: Decorator with arguments (rate limiter style)

import time
from fastapi import FastAPI, HTTPException

app = FastAPI()

def rate_limit(seconds: int):
    last_called = {}

    def decorator(func):
        async def wrapper(*args, **kwargs):
            now = time.time()
            if func.__name__ in last_called and now - last_called[func.__name__] < seconds:
                raise HTTPException(status_code=429, detail="Too many requests")
            last_called[func.__name__] = now
            return await func(*args, **kwargs)
        return wrapper
    return decorator

@app.get("/ping")
@rate_limit(5)   # limit calls to every 5 seconds
async def ping():
    return {"message": "pong!"}

First request works ✅
Second request within 5s → 429 Too Many Requests

🛠 Example 4: Class decorator for routes (like Django’s `@admin.register`)

def tag_routes(tag: str):
    def decorator(func):
        func._tag = tag  # attach metadata
        return func
    return decorator

app = FastAPI()

@app.get("/items")
@tag_routes("inventory")
async def get_items():
    return {"items": ["apple", "banana"]}

# Later you could inspect `get_items._tag` == "inventory"

✅ Summary for FastAPI decorators

Work same as Python decorators
Useful for:
- Logging
- Auth / API keys
- Rate limiting
- Attaching metadata
You can mix them with FastAPI’s built-in dependencies, but decorators give more fine-grained control.

Arrays, Lists, Dicts, and Sets Across Python, C++, and JavaScript

Muhammad Atif Iqbal — Tue, 02 Sep 2025 11:52:23 +0000

Comparison of Arrays, Lists, Dicts, and Sets Across Python, C++, and JavaScript

✅ 1. Arrays vs Dicts in Each Language

Concept	Python	C++	JavaScript
Array / List	`list = [10, 20, 30]`	`int arr[3] = {10, 20, 30};` or `vector<int> arr = {10, 20, 30};`	`let arr = [10, 20, 30];`
Dictionary / Map (Key-Value)	`d = {"a": 1, "b": 2}`	`map<string, int> d = {{"a", 1}, {"b", 2}};`	`let d = {a: 1, b: 2};` or `let d = new Map([["a", 1], ["b", 2]]);`
Set (Unique elements, unordered)	`s = {1, 2, 3}`	`set<int> s = {1, 2, 3};`	`let s = new Set([1, 2, 3]);`

✅ 2. Why "Array" is called "List" in Python & JavaScript

In C++, array is a low-level fixed-size container. Example:

  int arr[3] = {1, 2, 3}; // Size is 3, cannot change

In Python and JavaScript, arrays are dynamic and resizable, so they are closer to C++ vector:

  arr = [1, 2, 3]
  arr.append(4)   # can grow

  let arr = [1, 2, 3];
  arr.push(4);   // can grow

👉 That’s why Python calls it list, not array, because it’s flexible.
👉 JS still calls it Array, but it behaves like a Python list.

✅ 3. Why C++ Arrays are Declared with `{}` not `[]`

Square brackets [] → specify size/index.

  int arr[3]; // array of size 3

Curly braces {} → specify values for initialization.

  int arr[3] = {10, 20, 30}; // initialize

So:

[] → size
{} → values

✅ 4. C++ 3D Array Example

A 3D array = array of arrays of arrays.
Example: a cube 2 × 3 × 4

#include <iostream>
using namespace std;

int main() {
    int arr[2][3][4] = {
        { {1, 2, 3, 4}, {5, 6, 7, 8}, {9, 10, 11, 12} },
        { {13, 14, 15, 16}, {17, 18, 19, 20}, {21, 22, 23, 24} }
    };

    cout << arr[1][2][3];  // Output: 24
}

👉 Think of it as a box with 2 layers, each having 3 rows, each row having 4 columns.

✅ 5. Sets in Each Language

Python

  s = {1, 2, 3, 3}
  print(s)  # {1, 2, 3} (removes duplicates)

C++

  #include <set>
  set<int> s = {1, 2, 3, 3};
  for (int x : s) cout << x << " ";  // 1 2 3

JavaScript

  let s = new Set([1, 2, 3, 3]);
  console.log(s);  // Set(3) {1, 2, 3}

👉 Difference with {} in Python

{} in Python by default = dict (empty dictionary).
set() must be used for empty set.

a = {}       # dictionary
b = set()    # empty set

👉 In C++ {} is not a set—it’s array initializer.

✅ 6. Quick Example Comparison

Array / List

Python: arr = [10, 20, 30]
C++: int arr[3] = {10, 20, 30};
JS: let arr = [10, 20, 30];

Dictionary / Map

Python: {"x": 1, "y": 2}
C++: map<string, int> d = {{"x",1},{"y",2}};
JS: {x:1, y:2} or new Map([["x",1],["y",2]])

Set

Python: {1, 2, 3}
C++: set<int> s = {1, 2, 3};
JS: new Set([1, 2, 3])

✅ So summary:

C++ arrays = low-level, fixed size.
Python list / JS Array = dynamic array (like C++ vector).
Dict/Map = key-value store (different thing).
Set = unique elements in all three.

Django vs Flask vs FastAPI

Muhammad Atif Iqbal — Mon, 01 Sep 2025 15:00:07 +0000

Django vs Flask vs FastAPI: A Complete Comparison

When building a web application in Python, three popular frameworks often come up in discussions: Django, Flask, and FastAPI. Each has its own strengths, weaknesses, and use cases. Choosing the right one depends on your project requirements, scalability goals, and developer experience.

1. Django

Overview

Django is a high-level, full-stack web framework designed for rapid development. It comes with batteries-included philosophy, meaning most of the essential features (ORM, authentication, admin panel) are built-in.

Key Features

Built-in ORM for database operations
Authentication and Authorization out of the box
Admin interface for managing data
Template engine for rendering HTML
Follows MTV (Model-Template-View) pattern

Pros

Great for large projects needing structure
Mature ecosystem with lots of third-party packages
Strong community and documentation
Excellent for applications where you need an admin panel and a lot of built-in tools

Cons

Heavyweight compared to Flask and FastAPI
Less flexible (you often need to follow Django’s way of doing things)
Not as fast as FastAPI for APIs

Best Use Cases

Enterprise applications
Content-heavy websites (CMS, e-commerce)
Projects where rapid prototyping with an admin panel is needed

2. Flask

Overview

Flask is a lightweight, micro web framework. Unlike Django, it doesn’t force you to use an ORM or specific tools. It’s very flexible and lets developers pick their own components.

Key Features

Minimal, simple, and easy to get started
Jinja2 templating engine
Extensions available for ORM (SQLAlchemy), authentication, etc.
Designed for flexibility

Pros

Very lightweight and flexible
Easy to learn and understand
Perfect for small APIs or web apps
Great choice when you need full control over architecture

Cons

No built-in ORM, authentication, or admin (everything must be added manually)
Can lead to “reinventing the wheel” for larger apps
Not the fastest (synchronous, unless extended with async libraries)

Best Use Cases

Small to medium APIs
Prototypes and learning projects
Apps where you need complete freedom in choosing tools

3. FastAPI

Overview

FastAPI is a modern, high-performance web framework for building APIs with Python. It’s built on Starlette (for the web parts) and Pydantic (for data validation). It is designed with asynchronous support and automatic OpenAPI/Swagger documentation.

Key Features

Built-in async/await support
Automatic generation of interactive API docs (Swagger & ReDoc)
Strong typing with Pydantic models
Extremely fast performance (comparable to Node.js and Go)

Pros

Very fast (close to raw Starlette speed)
Great for modern APIs and microservices
Automatic validation and documentation saves time
Strong typing makes debugging and scaling easier

Cons

Relatively younger framework (less mature ecosystem than Django/Flask)
Smaller community compared to Django
Not ideal for traditional monolithic web apps with templates and admin

Best Use Cases

REST APIs and microservices
Real-time applications (chat, IoT, etc.)
Machine Learning/AI apps (where performance matters)

4. Performance Comparison

Feature	Django 🟦	Flask 🟧	FastAPI 🟩
Learning Curve	Moderate	Easy	Moderate
Performance	Medium	Medium	High
Async Support	Limited	Partial	Native
Built-in Tools	Many	Few	Moderate
Community & Ecosystem	Large	Large	Growing
Best for	Full apps	Small apps	APIs & microservices

5. Which One Should You Choose?

Choose Django if you’re building a large web application with a database, admin panel, and built-in tools. (e.g., e-commerce site, CMS, ERP)
Choose Flask if you need a simple, lightweight solution or you want full control with minimal dependencies. (e.g., small APIs, prototypes)
Choose FastAPI if you’re building modern APIs or microservices where speed and scalability matter. (e.g., ML model serving, real-time apps)

✅ In short:

Django = batteries included (big projects, admin dashboards)
Flask = flexibility (small projects, learning, custom solutions)
FastAPI = speed & modern APIs (microservices, AI/ML backends)

`inspect.stack()` in Python with Examples

Muhammad Atif Iqbal — Fri, 29 Aug 2025 10:20:31 +0000

🔍 Understanding `inspect.stack()` in Python with Examples

When you use Python’s inspect.stack(), it gives you a list of frames representing the current call stack.
Each element is a 6-tuple:

frame (frame_record[0]) → The execution environment (locals, globals).
filename (frame_record[1]) → The file name where the code lives.
lineno (frame_record[2]) → The line number being executed.
function (frame_record[3]) → The function name being executed.
code_context (frame_record[4]) → A snippet of source code being run.
index (frame_record[5]) → Which line of the code context is active.

Let’s break these with 5 different examples each.

1. Frame (`frame_record[0]`)

This is the actual frame object: an environment where Python is executing.
You can use it to see local variables.

Examples

import inspect

def foo(x):
    stack = inspect.stack()
    frame = stack[0][0]   # current frame
    print(frame.f_locals) # show local variables

foo(10)

👉 Output: {'x': 10, 'stack': [...], 'frame': <frame object ...>}

Other uses:

See which variables are in scope.
Modify local variables dynamically (advanced).
Access global variables.
Debugging when you don’t know what’s available.
Introspection tools (like Django debug toolbar).

2. Filename (`frame_record[1]`)

This gives you the file name where the function is running.

Examples

import inspect

def bar():
    stack = inspect.stack()
    print(stack[0][1])  # filename

bar()

👉 Output: /home/user/my_script.py

Other uses:

Logging errors with file location.
Auto-documentation (e.g., Sphinx-like tools).
Debugging when you forget which file a function lives in.
Security: detect if code is executed from a wrong file.
Cross-file function tracing.

3. Line Number (`frame_record[2]`)

This tells you the line number inside the file.

Examples

import inspect

def baz():
    stack = inspect.stack()
    print(stack[0][2])  # line number

baz()

👉 Output: 7 (or whatever line print is on)

Other uses:

Show where an error happened.
Trace execution step-by-step.
Build a debugger.
Logging warnings with file + line.
Unit test coverage tools.

4. Function (`frame_record[3]`)

This gives you the function name currently executing.

Examples

import inspect

def alpha():
    stack = inspect.stack()
    print(stack[0][3])  # function name

alpha()

👉 Output: alpha

Other uses:

Dynamic logging (Entering function alpha).
Profiling which function runs slow.
Security: check only certain functions run.
Frameworks (like Django middleware) detect caller.
Debugging complex recursive functions.

5. Code Context (`frame_record[4]`)

This is a list of lines of code currently running.
It’s usually 1 line.

Examples

import inspect

def beta():
    stack = inspect.stack()
    print(stack[0][4])  # code context

beta()

👉 Output: ['print(stack[0][4]) # code context\n']

Other uses:

Show exact line being run (like traceback).
Pretty error printing.
Static analyzers (linting tools).
Debugger that shows current code.
Learning tools that display executed code.

6. Index (`frame_record[5]`)

This is the index of the line in the code_context list.
Usually it’s 0, but if multiple lines exist, it shows which one is running.

Examples

import inspect

def gamma():
    stack = inspect.stack()
    print(stack[0][5])  # index

gamma()

👉 Output: 0

Other uses:

Multi-line expressions debugging.
Syntax highlighting for running line.
Editors showing current cursor position.
Teaching tools for step-by-step code.
Debuggers aligning executed line.

✅ Summary

frame → Execution environment (variables).
filename → Which file is running.
lineno → Which line number.
function → Which function name.
code_context → The actual code text.
index → Position inside that code.

What is difference between Django and DRF ( Django REST Framework )

Muhammad Atif Iqbal — Thu, 28 Aug 2025 11:48:20 +0000

🔹 1. Django

What it is:
Django is a full-stack web framework for Python.
It helps you build websites and web apps (with HTML templates, forms, authentication, ORM, admin panel, etc.).
Main focus:
Django is designed to create server-rendered web pages (like traditional websites).
Example use case:
- Blog website
- E-commerce site
- Admin dashboard with HTML pages
Typical flow:

Browser → URL → Django view → HTML template → Browser displays webpage.

🔹 2. Django REST Framework (DRF)

What it is:
DRF is a third-party library built on top of Django.
It’s not a separate framework — it extends Django to build REST APIs.
Main focus:
DRF is designed to send and receive data (usually JSON), not HTML.
It turns your Django models into RESTful API endpoints.
Example use case:
- Mobile app backend (iOS/Android need JSON, not HTML)
- SPA frontend (React, Vue, Angular) that fetches data via API
- Exposing APIs to third-party developers
Typical flow:

Mobile App / React Frontend → API Request → DRF view → JSON Response.

🔹 3. Key Differences

Feature	Django	DRF (Django REST Framework)
Purpose	Build websites (HTML templates)	Build APIs (JSON, XML, etc.)
Response Type	HTML (via templates)	JSON / other API formats
Views	`views.py` with `HttpResponse`/`render()`	`APIView`, `ViewSet`, `GenericViewSet`
Serialization	Not needed (works with templates)	Required (`Serializer` converts model → JSON and back)
Authentication	Session-based auth (cookies)	Token/JWT/OAuth (API-friendly)
Front-end Integration	Tightly coupled (Django renders HTML)	Decoupled (React, Vue, Flutter, Mobile apps use APIs)

🔹 4. Example

Django View (HTML)

# views.py
from django.shortcuts import render
from .models import Article

def article_list(request):
    articles = Article.objects.all()
    return render(request, "articles.html", {"articles": articles})

This returns an HTML page.

DRF API View (JSON)

# views.py
from rest_framework.response import Response
from rest_framework.views import APIView
from .models import Article
from .serializers import ArticleSerializer

class ArticleListAPI(APIView):
    def get(self, request):
        articles = Article.objects.all()
        serializer = ArticleSerializer(articles, many=True)
        return Response(serializer.data)

This returns JSON like:

[
  {"id": 1, "title": "Hello World", "content": "First article"},
  {"id": 2, "title": "Another Post", "content": "Second article"}
]

🔹 5. When to use which?

Django only → If you’re building a traditional website where backend renders HTML (like WordPress-style blog, admin dashboards).
Django + DRF → If you’re building a backend for mobile apps, SPAs (React, Vue), or APIs for third-party use.

✅ In short:

Django → Web pages
DRF → APIs (JSON)

DEV Community: Muhammad Atif Iqbal

What is Robocorp?

🧠 1. What is Robocorp?

Also Read Robocorp and RPA: The Complete Guide to Open-Source Robotic Process Automation Using Python

⚙️ 2. What is RPA (Robotic Process Automation)?

🤖 3. What is Robocorp RPA?

🧩 Example of Robocorp RPA in action:

🆚 In short:

Django formfield_for_foreignkey() function

Mastering Django formfield_for_foreignkey: Complete Guide with Examples

1. What is formfield_for_foreignkey?

2. How Django Handles ForeignKey by Default

3. Real-World Use Cases

Example 1: Filter by Logged-In User

Example 2: Show Only Active Records

Example 3: Sort Dropdown Alphabetically

Example 4: Restrict by Permissions

Example 5: Multi-Tenant Filtering

4. When to Use It?

5. Best Practices

6. Common Mistakes

7. FAQs

8. Final Thoughts

'formfield_for_foreignkey()' with Django Permissions: Fine-Grained Control in Admin

What is formfield_for_foreignkey?

Why Combine with Permissions?

Example 1: Restrict by Permission

Example 2: Role-Based Dropdown Filtering

Example 3: Handling Sensitive Data

Example 4: Multi-Tenant Use Case

Best Practices

Final Thoughts

How to Restrict ForeignKey Choices in Django

Introduction

Why Does Django Show All ForeignKey Choices by Default?

When Do You Need to Restrict ForeignKey Choices?

The Django Way: Using formfield_for_foreignkey

Method Signature

Example 1: Restrict Choices to Logged-in User

Example 2: Restrict Choices Based on User Role

Example 3: Show Only Active Records

Alternative Approaches

1. Using limit_choices_to in the Model

2. Overriding the Form Class

Best Practices

Common Pitfalls

FAQs

❓ Can I restrict ForeignKey dropdowns outside the admin?

❓ Can I hide the dropdown completely?

❓ What if I want autocomplete instead of dropdown?

Conclusion

`formfield_for_foreignkey()` in Django Admin: A Complete Guide

Mastering formfield_for_foreignkey in Django Admin: A Complete Guide

🔎 What is formfield_for_foreignkey in Django Admin?

🛠 How Django Handles ForeignKey by Default

🚀 Example 1: Filter ForeignKey Choices by Logged-in User

🚀 Example 2: Show Only Active Related Objects

🚀 Example 3: Sort the Dropdown Options

🔑 When Should You Use formfield_for_foreignkey?

⚡ Best Practices

🎯 Final Thoughts

Demystifying db_field in Django Admin

For complete article please visit db_field in Django Admin

What is db_field?

Where is db_field Used?

Example 1 — Filtering a ForeignKey

Example 2 — Customizing Choices

Example 3 — Catch-All with formfield_for_dbfield

Why is db_field Useful?

Key Takeaways

What is threading in Python?

🔹 What is threading in Python?

🔹 Why use threading in Django?

🔹 What is _thread_local?

What is a Decorator in Python, Django and FastAPI?

🔹 Decorators in Python, Django and FastAPI in details with examples

🔹 Example 1 – Simple function decorator

🔹 Example 2 – Decorator with arguments

🔹 Example 3 – Django decorator

🔹 Example 4 – Class decorator (Django admin)

Mastering Django `formfield_for_foreignkey`: Complete Guide with Examples

The Django Way: Using `formfield_for_foreignkey`

1. Using `limit_choices_to` in the Model

Mastering `formfield_for_foreignkey` in Django Admin: A Complete Guide

🔎 What is `formfield_for_foreignkey` in Django Admin?

🔑 When Should You Use `formfield_for_foreignkey`?

What is `db_field`?

Where is `db_field` Used?

Example 3 — Catch-All with `formfield_for_dbfield`

Why is `db_field` Useful?

🔹 What is `_thread_local`?

🛠 Example 4: Class decorator for routes (like Django’s `@admin.register`)

✅ 3. Why C++ Arrays are Declared with `{}` not `[]`

🔍 Understanding `inspect.stack()` in Python with Examples

1. Frame (`frame_record[0]`)

2. Filename (`frame_record[1]`)

3. Line Number (`frame_record[2]`)

4. Function (`frame_record[3]`)

5. Code Context (`frame_record[4]`)

6. Index (`frame_record[5]`)