Report Views

Developer guide for the Enezaframework reporting engine. Part of the Add Report series.

Table of Contents

1. Overview
2. Unified Report Bases (Recommended)
3. How the Report Type Is Resolved
4. Legacy Views (Backward Compatible)
5. Commonly Used View Attributes
6. Type-Specific Context
7. Related Guides

Overview

Each unified base in enezareporting.report_base is the single parent for a report type. It already contains the type metadata, form building, generator dispatch, designer rendering, query-builder filters, and totals hooks, so report classes inherit exactly one class.

All unified bases live in enezareporting.report_base; the lower-level view classes remain in enezareporting.views.

Unified Report Bases (Recommended)

from enezareporting.report_base import TabularReportView
from enezareporting.parameters import ParameterSet, DateRangeParam
from myapp.models import SalesLine


class SalesReport(TabularReportView):
    report_model = SalesLine
    columns = ["item_description", "__total__"]
    parameter_spec = ParameterSet(
        DateRangeParam(name="date_range", start_field="date_placed"),
    )

Each base automatically:

1. Uses the report metadata from the class itself.
2. Builds the correct form from parameter_spec.
3. Instantiates the matching generator.
4. Adds type-specific context (document_header, drilldown_breadcrumb, and so on).
5. Applies designer layouts when design_slug is set and totals when add_totals = True.

classDiagram
    class BaseReportView
    class TabularReportView
    class SummaryReportView
    class DetailedReportView
    class CrosstabReportView
    class TimeSeriesReportView
    class DrillDownReportView
    class DocumentReportView
    class BaseDocumentReport

    BaseReportView <|-- TabularReportView
    BaseReportView <|-- CrosstabReportView
    BaseReportView <|-- TimeSeriesReportView
    BaseReportView <|-- DrillDownReportView
    TabularReportView <|-- SummaryReportView
    TabularReportView <|-- DetailedReportView
    BaseDocumentReport <|-- DocumentReportView

How the Report Type Is Resolved

Unified bases carry the report type metadata directly, so no MRO scan is needed: _resolve_report_type() returns the report class itself.

ReportEngineView remains available for advanced and legacy use. Its resolution order is:

1. If report_type_class is set, return it.
2. If the view class itself subclasses ReportType and has a parameter_spec, return it.
3. Otherwise scan the MRO for the first base with a parameter_spec.

Set report_type_class on ReportEngineView when you want to reuse one view class for several report types:

class GenericReportView(ReportEngineView):
    report_type_class = SalesReport

Legacy Views (Backward Compatible)

These classes continue to work:

Combining a pure report type with ReportEngineView still works but is deprecated and emits a DeprecationWarning; inherit the matching *ReportView base instead.

The legacy ReportView family builds its forms with report_form_factory() and uses report_generator_class (default ReportGenerator) rather than a unified report base.

Commonly Used View Attributes

These are defined on ReportViewBase and inherited by every unified base (enezareporting/views.py). Defaults shown are the actual defaults.

Type-Specific Context

The report view's get_context_data() injects context depending on the resolved type:

Related Guides

• Report Types Overview
• Report Templates
• Migrating to Unified Report Views
• BaseDocumentReport
• Add Report — Developer Index