Framework Overview

Developer guide for the Enezaframework. Part of the Developer documentation.

Table of Contents

1. What Enezaframework Is
2. Core Technologies
3. The Three App Types
4. Dependency Rules
5. How a Request Flows
6. Change History
7. Related Guides

What Enezaframework Is

Enezaframework is a low-code framework for Django that simplifies building CRUD (Create, Read, Update, Delete) functionality inside an ERP-style system. Instead of hand-writing list, detail, create, and delete views for every model, a developer declares a model and a small amount of configuration, then inherits ready-made base models and base views from the framework.

Problem solved: Standard ERP modules are dominated by repetitive CRUD screens. Writing them by hand is slow, inconsistent, and hard to maintain across many Small to Medium Enterprise (SME) systems.

Expected outcome: A developer defines the domain model, picks the correct base class, describes the form layout, and gets working list/detail/create/delete pages, navigation, and URLs with minimal custom code.

Who this guide is for: Django developers and coding agents building business apps on top of Enezaframework.

Core Technologies

The Three App Types

Every project is organized into three kinds of Django apps.

1. enezacommon

Shared domain data and choice definitions used across the whole system.

• Provides models such as Business, Person, User, and reusable choice classes such as VendorType and CustomerType.
• Designed to be independent of business-logic apps. Its only dependency is enezaframework.

2. enezaframework

The heart of the low-code framework.

• Defines the base models (EnezaModel, EnezaMaster, EnezaDocument, and others) that carry common fields and behavior.
• Provides generic base views that implement most CRUD operations.
• Provides utilities such as @auto_url_register, get_registered_urls, and load_icon.

3. Business Logic Apps

The apps that implement a specific system's functionality. They are usually organized around data models rather than high-level features.

• Examples: generalledger, accountpayable, expensereporting, inventorymanagement.
• They contain models inheriting from framework base models, and views inheriting from framework base views.

Dependency Rules

flowchart BT
    DJ[Django]
    EF[enezaframework]
    EC[enezacommon]
    BIZ[Business logic apps<br/>accountpayable, generalledger, ...]

    DJ --> EF
    EF --> EC
    EF --> BIZ
    EC -. shared models .-> BIZ

Rules to keep the layering clean:

1. enezaframework may depend on Django only.
2. enezacommon may depend on enezaframework and Django. It must not import business-logic apps.
3. Business apps may depend on both enezaframework and enezacommon. They must not import each other's internals to avoid cycles.

Register the framework and common apps in settings before the business apps that use them. Generated projects import the framework app list once:

from enezaframework.conf import ENEZA_APPS

INSTALLED_APPS = [
    # ... Django and third-party apps ...
    *ENEZA_APPS,
    # ... project and business apps ...
    "accountpayable",
]

ENEZA_APPS contains the framework, common, RBAC, reporting, dashboard, communication, administration, workflow, notification, agent and human-resource apps. Adding or removing a framework app is a one-line change in enezaframework/conf.py.

How a Request Flows

At a high level, a browser request is routed to a base view, the view reads or writes a model that inherits from a framework base model, and the framework's generic templates render the result. HTMX swaps partial templates into the current page instead of reloading everything.

sequenceDiagram
    participant Browser
    participant URL as urls.py
    participant View as Base view
    participant Model as Eneza base model
    participant Template as Generic template

    Browser->>URL: GET /accountpayable/vendortable/
    URL->>View: VendorTableListView
    View->>Model: query records
    Model-->>View: queryset
    View->>Template: render list template
    Template-->>Browser: HTML (full or HTMX partial)

The generic list/detail templates are supplied by Enezaframework, so most apps do not ship their own templates. See Standardized App Structure and Frontend Templates & UI Reuse.

Change History

Dated changes that affect this guide, taken from docs/Release note/CHANGELOG.md and the release notes. For the complete history, see the changelog.

Related Guides

• Standardized App Structure
• Developer Workflow
• Base Models & Model Types
• CRUD Base Views
• Back to the Developer index