E

Developer Workflow

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

Table of Contents

  1. Overview
  2. The Build Order
  3. Step 1: Define Models
  4. Step 2: Define Views
  5. Step 3: Define Menus
  6. Step 4: Migrate
  7. Step 5: Templates
  8. Step 6: URLs
  9. Checklist
  10. Change History
  11. Related Guides

Overview

Building a feature on Enezaframework follows a consistent order. This guide is the short operational version of the other guides in the series; follow the links for detail.

For a new app, scaffold it first:

bash
eneza startapp myapp --project-dir .

The CLI creates empty models/, views/ and migrations/ packages with __init__.py, no sample model or view, and a dashboard-first menu entry. Add the app to INSTALLED_APPS and the project URL configuration, then follow the steps below.

flowchart TD
    A[1. Define models] --> B[2. Define views]
    B --> C[3. Define menus]
    C --> D[4. Migrate]
    D --> E[5. Templates if needed]
    E --> F[6. Wire URLs]
    F --> G[Developer hands off for user testing]

The Build Order

Step Output Detail
1 Models inheriting framework base classes Base Models & Model Types
2 Views inheriting framework base views, decorated with @auto_url_register CRUD Base Views
3 menus in apps.py Menu & Navigation Configuration
4 Migrations applied This guide
5 Custom templates (only if needed) Frontend Templates & UI Reuse
6 urls.py aggregating generated routes URL Auto-Registration

Step 1: Define Models

  • Put each model in its own file under models/.
  • Inherit from the appropriate base (EnezaMaster, EnezaDocument, EnezaSetup, and so on).
  • Apply the field conventions: one field per line, verbose_name on every field, closing parenthesis on its own line for multi-line declarations.
  • Re-export every model from models/__init__.py.

See Standardized App Structure, How to Add a Model, and Model Field Conventions.

Step 2: Define Views

  • Put related views in files under views/.
  • Inherit from the appropriate base (BaseListView, BaseDetailView, BaseCreateView, BaseDeleteView, or a specialized variant).
  • Decorate every view with @auto_url_register.
  • Set model.
  • Implement set_list_fields and set_search_fields on list views.
  • Implement detail_ui_view on detail and create views.
  • Implement get_inline_related_objects where the record has related data.
  • Implement get_related_object_id where a one-to-one inline must be resolved.
  • Re-export every view from views/__init__.py.

See CRUD Base Views, Field & Inline UI Configuration, and Inline & Specialized Views.

Step 3: Define Menus

  • In apps.py, build or update the menus list so the views are reachable from navigation.
  • A new CLI app starts with menus = [] and app_entry_menu; the module menu opens the dashboard entry, which shows an empty state until a dashboard is designed.
  • Group menu items under meaningful fast tabs.
  • Use load_icon(name) for icons and confirm the icons/{name}.svg files exist in your static files.
  • Optionally set menu_verbose_name, app_entry_menu, app_icon, and menu_position.

See Menu & Navigation Configuration.

Step 4: Migrate

bash
python manage.py makemigrations <app_name>
python manage.py migrate

Fix any model errors before moving on; migrations must apply cleanly.

Step 5: Templates

  • Start by using the framework's generic templates; most apps need none of their own.
  • Only create a template under templates/<app_name>/ when the generic template cannot meet the requirement.
  • Reuse the base design, components, and static assets rather than rebuilding UI.

See Frontend Templates & UI Reuse.

Step 6: URLs

  • Set app_name in the app's urls.py.
  • Pull dynamic_urls = get_registered_urls(app_name).
  • Spread *dynamic_urls into urlpatterns alongside any manually defined paths.
  • Confirm the generated URL names match the ones referenced in menus.

See URL Auto-Registration.

Checklist

  • [ ] Models inherit a framework base class and are re-exported from models/__init__.py.
  • [ ] Every model field has a verbose_name; multi-line fields close on their own line.
  • [ ] Every view is decorated with @auto_url_register and sets model.
  • [ ] List views implement set_list_fields and set_search_fields.
  • [ ] Detail/create views implement detail_ui_view.
  • [ ] Inline relationships are declared in get_inline_related_objects; resolution added via get_related_object_id where needed.
  • [ ] Views are re-exported from views/__init__.py.
  • [ ] New app scaffold keeps models/, views/ and migrations/ packages with __init__.py.
  • [ ] menus entries reference the correct generated URL names and existing icons; a fresh app may keep menus=[] and use the dashboard entry empty state.
  • [ ] Migrations generated and applied.
  • [ ] urls.py includes *dynamic_urls.
  • [ ] User has been asked to test and validate the feature (the developer/agent does not test).

Per project rules, the developer or agent does not run or claim test results. The user is solely responsible for all testing and validation of the output.

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.

Date Version What changed
2026-07-05 0.2.13 Step 2 gained reusable tab groups (get_tab_groups()) and the tab_group inline key.
2026-07-10 0.2.16 Step 3/6 gained optional url_name, so generated URL names can differ from model names.
2026-08-23 0.2.19 Generated forms now render Boolean fields as a Yes/No select (BaseEnezaModelForm).
2026-10-31 0.2.22 New apps are scaffolded with eneza startapp; the scaffold has empty models/views/migrations packages and a dashboard-first menu entry with no sample view.

The ordered build steps themselves are unchanged for the 0.2.7–0.2.19 window; the entries above are refinements within existing steps.

View source Edit this page