Core classes

Official dbxapp website

This chapter explains the meaning and typical use of the main system classes. It is not a complete API reference; The detailed reference generates Doxygen directly from the source.

Architectural decision for large core classes

dbxDB, dbxDD, dbxForm and dbxReport They have many capabilities because they are system-wide facades and conditioned pipelines. Your public API keeps modules simple and uniform.

A division makes sense not only because of the number of lines or the number of methods. Internal responsibilities must only be extracted when there is a real life cycle limit, measurable benefit, full regression tests and a compatible facade. Domain modules shall then not use the internal subclasses directly.

The binding decision matrix and the complete interaction are under Mandatory module manual.

dbxApi / dbx()

dbx() is the central access point.

Typical tasks:

• Read request and module variables.
• Set remember and session values.
• Load system objects.
• Loading Include objects.
• Read the configuration/schreiben.
• state-changings delete-/Save-Links with ride over action url() automatically recognize and sign.
• use central auxiliary functions directly; Escaping only in the actually necessary output context.

Example:

For configuration, there is exactly one API: get cfg() reads basic and local values, set cfg() write it. Old parallel designations are not part of the interface. In demo mode, get cfg(..., true) provide a copy masked for display; set cfg() is always blocked.

dbxWebApp

dbxWebApp Performs the request:

• Determine the base URL.
• Resolve permalink or module route.
• automatically detected and check dbxReport-own action policies before the module starts.
• Detect writing dbxReport grid routes by their route, not by an optional transport marker.
• Design, language, edit mode.
• output content or module.
• CSS/JS.
• Finalize the output.

dbxInterpreter

The interpreter processes markers such as:

It runs for the website edition. In the template editor, it must not execute the edited raw text.

See also: dbxInterpreter Guide.

dbxTPL

Template engine for HTML templates, markers and template slots.

dbxDB

Data access, DD stores, rights, trace, performance, backup/Restore/Transfer. technical changes run exclusively through insert(), Update(), save() and delete(). In demo mode, the central rights check refuses these methods. Explicit system calls with verify access=0, especially the session life cycle, remain separate from it.

dbxDD

DD synchronisation, DD models, field/index structure, DB-to-DD and DD-to-DB.

dbxForm

Forms, panels, field construction, validation, messages, save pipeline and own rotating POST protection. init() handles the direct caller as a callback owner; Methods by which: {fid {event } They are found without registration. add rep() and replaces() form the common template replacement pipeline. Normal form actions do not require additional dbx token.

dbxReport

Lists, search, sorting, pagination, actions, multi-select, grid mode and automatic signing of mutating standard actions. In the grid, read URLs are left unchanged; Save, Insert, Delete, Sort and Sync are signed according to the binding grid route convention and unknown write URLs are rejected securely. Calculated fields and sums belong by default in {fid} next record; Delayed add rep()Values are available to the footer. {rpt:col count Give all the columns, {rpt:colspan all columns except the last column. Explicit owner or callback setters are only necessary for deliberately different method names.

dbx session

Session management and optional session DB. Normal HTTP requests and HTML-AJAX requests can write session status at the request end. Pure JSON-AJAX actions do not necessarily have to write Session/Performance. Login and Logout discard the action token secret of the previous security context.

dbxMail

Mail delivery via the configured mail infrastructure.

dbxValidator

Validate request, form and field values. The current technical rules contain among other things email for full Internet e-mail addresses and permalink for flat CMS permalinks made up of lowercase letters, numbers and single dashes.

dbxUpload / dbxDownload

Upload/download functions, file verification and image editing.

dbxProcess

Status and process management for longer operations such as sync, import, transfer or batch actions.

dbxUpdateService

The file-based system updater is centrally located in dbxAdmin. Modules do not build their own download, installation or update functions.

The normal administrator flow has two secure phases:

1. Automatically prepare the update: Preparation() Checks the fixed GitHub manifesto, compares the version, loads a newer package, and checks HTTPS target, PHP requests, SHA-256, ZIP paths, symlinks, file inventory, and each individual file. Installed program files are not yet changed.
2. Decision: install() Secures and installs the prepared package. Cancel() stops the process beforehand and completely removes ZIP, staging and status.

Mutant update operations are serialized by a central file lock. The short file exchange must not be interrupted manually: If there is an error install() automatically restore the previously created file backup. After a successful installation rollback() available for the last version.

The updater never directly accesses DB3 or MySQL. Data changes remain DD-driven dbxDB-Migrations and must be explicitly described in the release notices. Files /, local config.local.phpUploads, sessions, caches and logs are neither shipped nor replaced.

Display in admin dashboard and menu

Status and Health, dashboard navigation and quick access display the update state centrally:

• test: There is no local test bed yet.
• Current: The last tested stable level is not newer.
• new: A more recent stable release is available.
• Ready: ZIP, checksum, inventory and staging are fully checked; the administrator can continue the installation or stop the update.

These advertisements are exclusively dbxUpdateService::status() on. The method reads the local state files/update and expressly does not perform a network call. Only the update page starts with Preparation() A new GitHub exam. This keeps the dashboard fast and a failure of GitHub affects neither menu nor system status.

All interfaces obtain the service configuration via dbxUpdateService::configured(). URL, cache time, security check, installation, stop and rollback thus remain defined in one place.

dbxView

Help for target areas, view-state and AJAX targets.

Basic rule

Kernel classes are infrastructure. Domain modules should use them, not copy them. Kernel changes only upon explicit request.

Read more: Mandatory module manual, dbxDB, dbxDD and FD, dbxForm and dbxReport.