Django Project Rules

djangopythonbackend

Enforces Django conventions including app organization, model design, view patterns, serializer usage, and security best practices for Python web applications.

Целевые файлы

Файл	Формат
.cursorrules	plaintext
CLAUDE.md	markdown

Содержимое

## Django Project Rules ### Project & App Structure - Split functionality into focused Django apps; each app handles one domain - App directory must contain: `models.py`, `views.py`, `urls.py`, `admin.py`, `tests/` - Keep `settings.py` split: `base.py`, `development.py`, `production.py` via `DJANGO_SETTINGS_MODULE` - Store secrets in environment variables, never in `settings.py` — use `python-decouple` or `django-environ` - Register all custom apps in `INSTALLED_APPS` using `AppConfig` with `default_auto_field` ### Models - Every model must have a `__str__` method returning a human-readable representation - Use `verbose_name` and `verbose_name_plural` in `Meta` class - Define `ordering` in `Meta` for models that have a natural order - Use `db_index=True` on fields used in frequent lookups and foreign keys - Use `select_related()` for ForeignKey and OneToOneField to avoid N+1 queries - Use `prefetch_related()` for ManyToManyField and reverse FK relations - Use `get_or_create()`, `update_or_create()` for atomic upsert operations - Custom model managers go in `managers.py`; override `get_queryset()` for default filtering ### Views - Prefer class-based views (CBVs) for CRUD operations; use `ListView`, `DetailView`, `CreateView` etc. - Use function-based views (FBVs) for complex, non-standard logic that CBV mixins obscure - Apply `@login_required` or `LoginRequiredMixin` to all authenticated views - Use `get_object_or_404()` instead of `.get()` for public detail views - Never put business logic in views — delegate to services or model methods - Use `context_object_name` in CBVs for readable template variables ### Forms & Serializers - Use `ModelForm` for forms tied to models; define `fields` or `exclude` explicitly — never use `fields = '__all__'` - Validate data in `clean_<fieldname>()` and `clean()` methods, not in views - Use Django REST Framework `ModelSerializer` for API views; always specify `fields` explicitly - Use `SerializerMethodField` for computed fields; keep serializers thin ### Admin - Register all production models in `admin.py` with a `ModelAdmin` class - Define `list_display`, `list_filter`, `search_fields`, `ordering` for every registered model - Use `readonly_fields` for auto-generated fields (created_at, updated_at, uuid) - Protect sensitive admin actions with `has_delete_permission` overrides ### URL Patterns - Use `app_name` in `urls.py` for namespacing: `app_name = 'users'` - Use named URL patterns: `path('profile/', views.profile, name='profile')` - Reference URLs with `reverse()` or `{% url %}` — never hardcode paths - Organize URLs by app; include app URLs in the root `urlconf` ### Security - Never disable `CSRF_COOKIE_SECURE`, `SESSION_COOKIE_SECURE`, or `SECURE_SSL_REDIRECT` in production - Use `Django.contrib.auth` for authentication — do not implement custom auth from scratch - Sanitize user input that will be rendered as HTML — use `mark_safe()` only on explicitly trusted strings - Set `DEBUG = False` and `ALLOWED_HOSTS` correctly in production ### Database & Migrations - Every model change must have a corresponding migration - Do not edit applied migrations — create new ones - Use `RunPython` for data migrations; always provide a reverse function - Run `migrate` before deploying — never skip migrations in CI/CD ### Anti-patterns - Do not use raw SQL unless absolutely necessary; use the ORM - Do not access `request.user` in models or signals — pass it explicitly - Do not import models at the module level in `apps.py` — use `AppConfig.ready()` - Do not use mutable default arguments in model field definitions

CLI

npx mindaxis apply django-rules --target cursor --scope project

Используется в паках

Django API

Robust Django REST API development

Открыть пак →

← Правила