Hi Django community,
I recently published the first beta of dj-hyperview, a Django package for building server-driven mobile applications with Hyperview.
Hyperview renders native mobile interfaces from HXML returned by a server. It deliberately works with any HTTP backend, but a Django project still needs to answer several practical questions: Where do HXML templates live? How are full documents and update fragments returned with the correct media types? When are templates validated? How do filesystem, database, and cached templates remain consistent?
dj-hyperview brings those backend responsibilities together using normal Django patterns while leaving every screen, URL, context object, and product decision inside the consuming project.
The request path
The core flow is intentionally small:
Hyperview request
↓
Django view → template resolver → filesystem, database, or custom source
↓
Django template rendering → HXML validation → document or fragment response
The package does not ship application screens or a mobile runtime. Your Django project owns the HXML and the Hyperview client decides how to render it.
Minimal example
Install the base package:
uv add dj-hyperview
Create hyperview/screens/home.xml:
<?xml version="1.0" encoding="UTF-8"?>
<doc xmlns="https://hyperview.org/hyperview">
<screen id="home">
<body>
<view>
<text>Hello from Django</text>
</view>
</body>
</screen>
</doc>
Configure the template source:
HYPERVIEW = {
"TEMPLATE_DIRS": [BASE_DIR / "hyperview"],
"SOURCES": [
{"BACKEND": "dj_hyperview.sources.FileSystemSource"},
],
}
Then expose it through a regular Django URL:
from django.urls import path
from dj_hyperview import HyperviewTemplateView
urlpatterns = [
path(
"hyperview/home/",
HyperviewTemplateView.as_view(template_name="screens/home.xml"),
),
]
The response is rendered lazily and returned as application/vnd.hyperview+xml. For replace, append, and prepend updates, HyperviewFragmentTemplateResponse returns one bare element as application/vnd.hyperview_fragment+xml and rejects document roots that would violate Hyperview’s fragment contract.
Filesystem and database templates
Template sources are ordered, and the first match wins. A project can therefore keep its normal filesystem templates as a fallback while placing selected screens in the database:
HYPERVIEW = {
"TEMPLATE_DIRS": [BASE_DIR / "hyperview"],
"SOURCES": [
{"BACKEND": "dj_hyperview.contrib.database.sources.DatabaseSource"},
{"BACKEND": "dj_hyperview.sources.FileSystemSource"},
],
}
The optional database application adds revision-aware publication and Django Admin integration. The optional editor extra provides HXML-aware editing, formatting, completion, and context-free validation before saving. Database templates are Django template code, so mutations are restricted to superusers by default and projects can provide their own permission callback.
This is useful when selected interfaces need to be updated without deploying the application code, but it does not turn a revision number into version history or rollback. Projects still need their own operational policy for reviewing, backing up, and recovering stored templates.
Validation, caching, and realtime hints
Rendered HXML is checked before bytes reach the client. The beta includes XML safety limits and automatic XSD 1.1 validation against a corrected Hyperview 0.110.0 schema. Projects can extend the schema for their own custom elements and behaviors.
Caching is optional and uses Django-compatible cache backends, including shared Redis deployments. Cache keys are source-aware, and committed template changes use generation-based invalidation so another worker does not continue serving an older template.
The optional realtime extra adds Redis-backed SSE invalidation hints. These events do not push arbitrary HXML into the client. They tell an authenticated application that a known resource changed, allowing the client to refresh only the affected screen or fragment using its normal Hyperview request flow.
Testing it with HyperTodo
I built HyperTodo as an open-source test application rather than a minimal showcase. It has a Django backend and an Expo/Hyperview client, and exercises filesystem and database templates, fragment replacement, Admin editing, shared caching, custom HXML components, localization, themes, biometrics, file uploads, and realtime refresh behavior.
The goal is to keep the package honest against an application with real navigation, forms, partial updates, and device integrations instead of validating it only through isolated examples.
Current compatibility and feedback
The current release is 0.1.0b1 and supports:
- Python 3.12, 3.13, and 3.14
- Django 5.2 and 6.1
- Hyperview 0.110.0
This is a beta intended to gather integration feedback, not a claim of production readiness. I would particularly value feedback on the public API, configuration model, database and Admin workflow, validation boundaries, and whether the documentation makes the Django-to-Hyperview request lifecycle clear.
Links:
Thanks for taking a look. Questions, integration experiences, and critical feedback are very welcome.