Frontend Templates & UI Reuse
Developer guide for the Enezaframework. Part of the Developer documentation.
Table of Contents
- Overview
- Generic Templates Shipped by the Framework
- Reuse the Vristo Template
- Static CSS and JS
- HTMX and Alpine.js
- Icons
- When to Create a Template
- Change History
- Related Guides
Overview
Enezaframework's UI is built on a purchased HTML template (Vristo) plus Tailwind CSS, HTMX, and Alpine.js. The framework ships generic templates for CRUD flows, so frontend work is mostly about reusing existing markup and components rather than writing new UI.
flowchart LR
BASE[Base layout / template] --> COMP[Reusable components]
BASE --> CRUD[Generic CRUD templates]
BASE --> WIDGETS[Dashboard and chart widgets]
CRUD --> PAGES[App pages]
PAGES --> HTMX[HTMX partial swaps]
PAGES --> ALPINE[Alpine.js reactivity]Generic Templates Shipped by the Framework
Base views resolve their templates automatically, so most apps never reference these paths directly. They are listed here so you know where to look and what to override:
| View | Full template | HTMX partial |
|---|---|---|
BaseListView |
core/list_page.html |
core/partials/list_partial.html |
BaseDetailView |
core/partials/detail_partial.html |
core/partials/main_object_form.html (edit) |
BaseCreateView |
core/partials/create_right_modal.html |
core/partials/create_partial.html |
BaseParameter |
core/partials/detail_parameter_partial.html |
core/partials/create_parameter_partial.html |
| Setup views | setups/... |
setups/partials/... |
| Inline views | core/partials/detail_one-on_one_partial.html |
inline partials |
Override a template only by pointing the view's template_name / partial_template_name (or the
create/detail template attributes) at your own file — do not edit the framework templates.
Reuse the Vristo Template
The reference design lives in the vristo-html-template folder at the project root. Before building any
screen:
- Look for an existing page that already does something similar and reuse its structure and classes.
- Reuse the dashboard and chart widgets that ship with the template instead of introducing new chart widgets.
- Reuse existing HTML components and elements (buttons, cards, tables, modals, dropdowns) rather than recreating them.
- Keep the visual language consistent with the rest of the ERP.
Static CSS and JS
- Always reuse the CSS and JS that come with the template. They live under
vristo-html-template/assets. - Do not pull in a second copy of a library the template already bundles.
- Ensure the Django static files configuration points at the same assets the template uses.
HTMX and Alpine.js
The framework uses HTMX for server-driven partial updates and Alpine.js for client-side state.
- HTMX — inline tabs, list updates, and action responses are loaded by swapping partial templates
into a container (for example
#detail-container) rather than reloading the page. The list and detail base views return partial templates when theHX-Requestheader is present. - Alpine.js — reactive widgets such as image uploads and field toggles update the DOM without a round trip.
POST requests require HTMX. BaseDetailView.post, BaseCreateView.post, and BaseParameter.post
return HTTP 400 when the request is not an HTMX request. If you build a custom form submission, send it
through HTMX (for example with hx-post).
When adding interactivity, prefer the patterns already used by the framework templates over bespoke JavaScript.
Icons
Icons are SVG files in a static icons/ folder (for example static/icons/). They are rendered with
load_icon(name, width=24, height=24), which resolves icons/{name}.svg. Use the same helper in menus
and in detail_ui_view tab/action definitions so the icon key matches a real file. See
Menu & Navigation Configuration.
When to Create a Template
Create an app-specific template only when the generic framework templates cannot express the requirement:
- Confirm no generic template or existing component covers it.
- Place it under
templates/<app_name>/. - Reuse the base layout and existing components.
- Load app static assets consistently with the rest of the project.
Most CRUD apps should ship zero custom templates.
The user is solely responsible for testing and validating the rendered UI; the developer/agent does not run the application.
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-06-30 | 0.2.8 | Quill rich-text, button-group, and label-field widgets and template tags added. |
| 2026-07-05 | 0.2.13 | Dynamic tab bar plus reusable fieldtabs_accordion.html; dark mode became the default theme; inline accordion toggle fixed. |
| 2026-07-06 | 0.2.14 | htmx.process(targetElement) added after form save so inline lists reload. |
| 2026-07-17 | 0.2.18 | Setup templates gained initTomSelects() calls for M2M widgets. |
| 2026-08-23 | 0.2.19 | TomSelect auto-initializes on DOMContentLoaded and after every HTMX swap; sidebar menu state persistence; Boolean fields render as Yes/No. |