Party Template Context

Developer guide for the Enezaframework party system. Part of the Party System series.

Table of Contents

  1. Overview
  2. Parent Detail Page Context
  3. Party Inline Context
  4. Choosing the Right Primary Key
  5. Template Snippets
  6. Context Origin Map
  7. 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):

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):

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