System Overview

This page explains how the main parts of dbxapp work together. Treat it as a map of the platform; the linked guides cover each area in depth.

dbxapp in one paragraph

dbxapp is a modular PHP platform for public websites, managed content, administration tools and custom business applications. A shared runtime brings together routing, permissions, data models, forms, reports, templates, browser features and caching.

Common application concerns therefore do not have to be rebuilt for every module. New features use defined platform services, which makes them easier to test, maintain and update.

Architecture at a glance

index.php, the request pipeline and dbx()

Start the runtime, establish the request context and expose the central system API.

Modules and routes

Map a request to a business capability. A module contains its controllers, services and related system resources.

dbxDB, DD and FD

dbxDB is the mandatory data-access layer. DD files describe tables, fields, indexes and permissions; FD files define reusable form views.

dbxForm and dbxReport

Handle validation, form state, persistence, search, sorting, pagination, selection and actions.

Content, menus, templates and designs

Define page structure and presentation. The public frontend primarily uses CMS pages and permalinks, while administration tools use modules and request parameters.

JavaScript system libraries

Add AJAX, dialogs, windows, confirmation flows, reports, grids, editor features and persistent UI state to the server-rendered interface.

How a response is produced

1. index.php starts the request pipeline.
2. The runtime resolves the installation, language, user, design, route and permissions.
3. The selected module runs its business logic and, when required, accesses data through dbxDB and a complete DD.
4. dbxForm, dbxReport or a domain service produces the application result.
5. Templates and the interpreter assemble the response. Code examples displayed in the documentation remain inert.
6. Output filters, metadata and the selected design complete the page. Eligible public pages can then be served from the full-page guest cache.

Choose the right building block

Update-safe extension boundaries

• Platform-wide changes: Kernel and shared-module changes belong in the product source. They are tested and delivered through the release and update process.
• Installation-specific changes: Customer logic, local integrations and custom workflows belong in myX or a dedicated domain module. This keeps them separate from kernel updates.
• Data access: Domain code uses dbxDB and complete DDs only. Direct PDO, mysqli, SQLite3 or native-driver access bypasses permissions, tracing, synchronization and system diagnostics.
• Presentation: HTML belongs in templates. PHP coordinates application behaviour instead of assembling large blocks of markup.
• Browser behaviour: Reuse or extend the supplied system libraries rather than creating parallel AJAX, window, dialog or UI-state implementations.

These boundaries make updates predictable: the product core can be replaced while project-specific extensions remain clearly separated and intact.

Common entry points

Public page

/kontakt
/produkte/lkw-planung
/de/service

Administration module

?dbx_modul=dbxAdmin
?dbx_modul=dbxContact_admin&dbx_run1=list
?dbx_modul=dbxAdmin&dbx_run1=sysmsg&dbx_run2=list_sysmsg

Module embedded in content or a template

[modul=dbxContact]dbx_run1=tickets[/modul]

Where to go next

• Architecture and runtime explains the request lifecycle in detail.
• myX demonstrates update-safe, project-specific extensions with a practical example.
• Module quick start walks through a complete module in one guided sequence.
• dbxDB, DD and FD covers data models, permissions and synchronization.

Key rule: New business features use the established dbxapp pipelines. Platform-wide capabilities become part of the product; installation-specific behaviour stays in myX or a dedicated domain module.