Party Template Context
Developer guide for the Enezaframework party system. Part of the Party System series.
Table of Contents
- Overview
- Parent Detail Page Context
- Party Inline Context
- Choosing the Right Primary Key
- Template Snippets
- Context Origin Map
- Related Guides
Overview
Party inlines are rendered inside the parent detail page and loaded over HTMX. Two primary keys are in play — the parent object's and the Party's — so the templates must use the right variable for the right inline. The framework adds party_object to both the parent and the inline context to make this possible.
Parent Detail Page Context
BaseDetailView.get_context_data() (enezaframework/views/base.py:162-191) adds:
| Variable | Description |
|---|---|
party_object |
The Party instance, or None if the model has no party yet. |
party_object.pk |
The Party primary key — used in inline HTMX URLs for party inlines. |
object |
The parent model instance. |
object.id |
The parent primary key — used in inline HTMX URLs for non-party inlines. |
inline_related_object |
The processed inline configuration (party + custom). |
Party Inline Context
The shared party inline views resolve the party from the main_object_pk query parameter. BaseInlineListView, BaseInlineDetailView, and BaseInlineCreateView each implement _resolve_party_object() (enezaframework/views/baseinline.py:45-53, 196-204, 392-400): when parent_model == Party, they load Party.objects.get(pk=main_object_pk).
| Variable | Description |
|---|---|
party_object |
The Party instance resolved from main_object_pk. |
party_object.pk |
Party PK — used in form actions, detail links, and delete links. |
main_object_pk |
The raw query parameter, kept for backward compatibility. |
The party partials (for example inline_details_add_con_partial.html, inline_create_add_con_partial.html) build their URLs with {{party_object.pk}}.
Choosing the Right Primary Key
flowchart TD
T[Inline URL on the detail page] --> Q{"inline_item.is_party_inline?"}
Q -->|Yes| PARTY["main_object_pk = party_object.pk"]
Q -->|No| PARENT["main_object_pk = object.id"]
PARTY --> RESOLVE["BaseInline*View._resolve_party_object()"]
RESOLVE --> POBJ["context['party_object']"]
POBJ --> ACTION["form action / links use {{ party_object.pk }}"]
PARENT --> STD["inline filtered by parent pk"]Rule:
- Party inline → resolve and act on the Party:
party_object.pk. - Everything else → the parent object:
object.id.
Template Snippets
Parent detail page — inline entry point (inline_items_section.html):
hx-get="{% url inline_item.app|default:current_app|add:':'|add:inline_item.url inline_item.related_object_id %}?main_object_pk={% if inline_item.is_party_inline %}{{party_object.pk}}{% else %}{{object.id}}{% endif %}"
Party inline partial — form action and list links (inline_create_add_con_partial.html):
<form ... action="{% url 'enezacommon'|add:':'|add:related_object_create_url_name %}?main_object_pk={{party_object.pk}}">
If you write a custom party partial, keep using {{ party_object.pk }} so the shared views can resolve the party. Using {{ object.id }} there would point the inline at the business record instead of the Party and break the party filter.
Context Origin Map
| Context | Added by | Variables used by party templates |
|---|---|---|
| Parent detail page | BaseDetailView.get_context_data() |
party_object, party_object.pk, object.id |
| Party inline list | BaseInlineListView.get_context_data() |
party_object, party_object.pk, main_object_pk |
| Party inline detail | BaseInlineDetailView.get_context_data() |
party_object, party_object.pk, main_object_pk |
| Party inline create | BaseInlineCreateView.get_context_data() |
party_object, party_object.pk, main_object_pk |