Inline & Specialized Views

Developer guide for the Enezaframework. Part of the architecture series.

Table of Contents

1. Overview
2. Inline Views
3. One-to-Many Inline Views (List + Detail)
4. BaseInlineOneToOneDetailView
5. Specialized Views
6. Journals Views
7. Setup Views
8. Document Views
9. Inline Template Context
10. Critical Rules
11. Related Guides

Overview

Beyond the core CRUD views, Enezaframework provides two families of views:

• Inline views manage records that belong to a parent record (one-to-many or one-to-one) and are rendered inside the parent's detail page.
• Specialized views behave like the core views but are tailored to a class of models (journals, setups, documents).

classDiagram
    class BaseDetailView
    class BaseListView
    class BaseCreateView
    class BaseDeleteView
    class BaseInlineListView
    class BaseInlineDetailView
    class BaseInlineCreateView
    class BaseInlineDeleteView
    class BaseInlineOneToOneDetailView
    class BaseJournalsListView
    class BaseSetupsListView
    class BaseSourceDocumentListView

    BaseInlineListView --|> BaseListView
    BaseInlineDetailView --|> BaseDetailView
    BaseInlineCreateView --|> BaseCreateView
    BaseInlineDeleteView --|> BaseDeleteView
    BaseInlineOneToOneDetailView --|> BaseInlineDetailView
    BaseJournalsListView --|> BaseListView
    BaseSetupsListView --|> BaseListView
    BaseSourceDocumentListView --|> BaseListView

Inline Views

Inline views are usually invoked by the parent detail view using HTMX, which swaps their content into an inline tab. The parent declares them in get_inline_related_objects; see Field & Inline UI Configuration.

One-to-Many Inline Views (List + Detail)

A child record that belongs to a parent (one-to-many) is edited inside the parent's detail page with two views: a BaseInlineListView that lists the children, and a BaseInlineDetailView that shows/edits one child. The parent declares the pair in get_inline_related_objects (see Field & Inline UI Configuration); the framework loads each view over HTMX into an inline tab.

from enezaframework.views import BaseInlineListView, BaseInlineDetailView
from enezaframework.utils import auto_url_register

from appname.models import ChildModel, ParentModel


@auto_url_register
class ChildModelInlineListView(BaseInlineListView):
    model = ChildModel
    parent_model = ParentModel
    related_name = "children"
    partial_template_name = "appname/partials/child_inline_list.html"
    url_name = "childmodel_inline"

    def set_list_fields(self):
        return ["field1", "field2"]

    def set_search_fields(self):
        return ["field1", "parent__name"]


@auto_url_register
class ChildModelInlineDetailView(BaseInlineDetailView):
    model = ChildModel
    parent_model = ParentModel
    related_name = "children"
    template_name = "appname/partials/child_inline_detail.html"
    url_name = "childmodel_inline"

    def detail_ui_view(self):
        return [
            {
                "name": "Report",
                "icon": "Home",
                "Fieldcolumns": [{"fields": ["parent"]}],
            },
        ]

    def get_context_data(self, **kwargs):
        context = super().get_context_data(**kwargs)
        # super() already sets main_object_pk and the related_object_* URL names.
        # Do not override main_object_pk here.
        return context

Required attributes:

Optional attributes:

set_search_fields() must be implemented, but the base list view does not currently apply it in get_queryset() — no search filtering happens out of the box.

The list view's get_queryset() filters children by the parent (main_object_pk) through find_field_by_related_name() (handles ForeignKey, OneToOne, ManyToMany, and GenericForeignKey) and by the current entity when the model has an entity field; results are ordered by -created_at.

BaseInlineOneToOneDetailView

Specialized for a related object in a strict one-to-one relationship with the parent.

Required attributes:

from enezaframework.views import BaseInlineOneToOneDetailView
from enezaframework.utils import auto_url_register
from accountpayable.models import VendorTable, VendorTableDetails


@auto_url_register
class VendorTableDetailsInlineView(BaseInlineOneToOneDetailView):
    model = VendorTableDetails
    parent_model = VendorTable
    related_name = "details"

    def detail_ui_view(self):
        Fieldtabs = [
            {
                "name": "Purchase demographics",
                "icon": "Home",
                "Fieldcolumns": [
                    {"fields": ["segment"]},
                ],
            },
        ]
        return Fieldtabs

For conditional or generic one-to-one inlines, the parent view supplies get_related_object_id to resolve the object being edited. Match the related_name used here with the relation_name declared in the parent's get_inline_related_objects.

Specialized Views

General pattern

Specialized views subclass the core views and add behavior (default filters, read-only enforcement, document layout). The child view still sets model and detail_ui_view, and is still decorated with @auto_url_register.

Journals Views

For models that inherit from a journal header/line base (for example JournalBatch and its lines).

Line views are typically used as inlines under BaseJournalsDetailView. Note that BaseJournalsDetailView and BaseJournalsLinesDetailView define action_list = [] and load inlines through get_inline_related_objects, so override those the same way you would on a core detail view.

Setup Views

For models that inherit from EnezaSetup (see Base Models & Model Types).

Read-only variants

Use the read-only variants when setup data must be visible but not editable in a given context or for a given role.

from enezaframework.views import BaseSetupsListview
from enezaframework.utils import auto_url_register
from accountpayable.models import VendorPostingGroup


@auto_url_register
class VendorPostingGroupListView(BaseSetupsListview):
    model = VendorPostingGroup

    def set_list_fields(self):
        list_fields = ["code", "description"]
        return list_fields

    def set_search_fields(self):
        search_fields = ["code", "description"]
        return search_fields

The class name is BaseSetupsListview (lowercase v). Import it from enezaframework.views.

Document Views

For "source document" models (sales orders, purchase invoices, and similar) that need a header/lines layout.

These views support the headerpostion tab key ("header" or "lines") so a tab's content renders in the document header region or alongside the lines.

def detail_ui_view(self):
    Fieldtabs = [
        {
            "name": "General",
            "icon": "Home",
            "headerpostion": "header",
            "Fieldcolumns": [
                {"fields": ["document_no", "customer"]},
            ],
        },
        {
            "name": "Lines",
            "icon": "Home",
            "headerpostion": "lines",
            "Fieldcolumns": [
                {"fields": ["total_amount", "currency"]},
            ],
        },
    ]
    return Fieldtabs

Inline Template Context

The base inline views populate the template context with routing and identity variables. Use these in custom inline templates instead of hard-coding URL names.

related_object_container_name differs between the two views: the list view sets it to model._meta.model_name, while the detail view sets it to model._meta.verbose_name.lower().replace(" ", ""). Keep this in mind if your list and detail templates share an hx-target id.

The inline detail template's back button uses these variables:

<button type="button"
        hx-get="{% url current_app|add:':'|add:related_object_list_url_name %}?main_object_pk={{ main_object_pk }}"
        hx-target="#{{ related_object_container_name }}-content">
    Back to List
</button>

Critical Rules

1. Decorate both inline views with @auto_url_register; do not add manual URL patterns for them in urls.py — the registry generates the routes (see URL Auto-Registration).
2. parent_model must be the model class (for example Risk), not a string like "riskmanagement.Risk".
3. Do not override get_list_url_name(), get_detail_url_name(), get_create_url_name(), or get_delete_url_name() — UrlMixin derives them from the model name / url_name.
4. Do not override main_object_pk in get_context_data() — the base view sets it from the request GET parameter.
5. url_name must match between the view class attribute and the url_name key in the parent's get_inline_related_objects() entry.
6. related_name on the view must match relation_name in the parent's inline config.
7. Import from enezaframework.views, not enezaframework.views.baseinline.

Related Guides

• CRUD Base Views
• Field & Inline UI Configuration
• Base Models & Model Types
• End-to-End CRUD Example (VendorTable)
• Full architecture reference