RAD Concept

On this page

dbxapp as Borland-inspired Web RAD Runtime

dbxapp target architecture

dbxapp as Borland-inspired Web RAD Runtime

dbxapp is designed to accommodate the best concept of old Borland systems: Application runtime, Components, clear life cycles, metadata, designer feeling and fast business development. dbxapp remains a modern PHP web application with DD, FD, templates, modules and client libs.

Application Runtime Components DD / FD Templates State Mobile web RAD

Guidance document

adopt Borland principles, but do not copy the old surface. dbxapp should be thought of as a domain RAD environment and still remain dbxapp.

What dbxapp should be

dbxapp is a server-side, component-based web application runtime for modular, Data-driven business applications.

dbxApp
  Runtime / Kernel
  Context / State
  Module
  Components
  DD / FD
  Templates
  Client Runtime

What dbxapp should not be

dbxapp should not be a Laravel clone, a WordPress clone and a pure React SPA. It should also not become a nostalgic desktop copy in the browser.

Nicht:
  alles als Fenster
  alles als Client-State
  alles als ORM
  alles als Controller
  UI-Spielerei vor Nutzen

Gold/diamond scale

Each new structure must make modules simpler, safer or more consistent. Beautiful architecture without concrete profit is not installed.

Gold:
  klar
  schnell
  sicher
  wiederverwendbar
  wenig Modulcode

Borland principles for dbxapp

1. Application Runtime instead of a loose PHP script

dbxapp starts, builds context, loads modules, creates components, collects output, renders templates and activates client behavior.

2. Components instead of functional collection

Forms, reports, grids, dialogs, windows and editors should be understood as components. A component has context, definition, state, behavior and output.

3. DD and FD as declarative designer layer

DD describes data and relationships. FD describes form/UI fields. Templates describe representation. Classes describe behavior and business logic.

4. Uniform life cycle

Every larger component should have the same process in the long term. This makes form, report, grid and window predictable.

construct
init_context
load_definition
load_state
read_request
validate
process
render
save_state

5. Central Runtime API over dbx()

Modules should not have to know many global functions. You should use few clear services.

dbx()->db()
dbx()->tpl()
dbx()->form()
dbx()->report()
dbx()->grid()
dbx()->dialog()
dbx()->window()
dbx()->get_modul_val()
dbx()->set_modul_val()
dbx()->get_remember()
dbx()->set_remember()

Module target image

Modules should be written quickly and safely. The module describes what it wants, not as dbxapp internally connects Request, State, DD, FD, Template, AJAX and Validation.

Report

$oReport = dbx()->report('sessions');
$oReport->set_dd('dbxSession');
$oReport->set_fd('dbxAdmin|rpt-sessions-selection');
return $oReport->run();

Form

$oForm = dbx()->form('customer');
$oForm->set_dd('customer');
$oForm->set_fd('myModule|customer-edit');
return $oForm->run();

Rule: Module code should remain technical. technical repetitions migrate into components, Base classes or dbx() services.

Mobile, tablet and app case

dbxapp remains a web application. Mobile and tablet are available via responsive components, Layouts and client ribs supported.

A later Android app would primarily be a WebView case with native bridges for mobile functions:

Camera File system Dates Addresses GPS Push Scanners

Important: These native functions are optional adapters. The core remains web, PHP, DD, FD, Templates, components and dbx() runtime.

Decision-making rules for conversions

Incompatible conceptual changes are discussed before implementation.
Obsolete burdens may be removed if the new way is clearer and better.
Existing atomic logic is not blindly replaced, but raised step by step.
New APIs must be named speaking.
Module code should contain fewer technical details, not more.
Each component must be able to restore its state meaningfully after reload.
Client Libs are component Libs: form.js, report.js, window.js, grid.js.
DD/FD/Templates/Klassen must remain visible in the editor and trace concept.

Proposed roadmap

Stage 1: Clarify language and structure

Define runtime terms, dbx()-API names, component lifecycle and module conventions. No hard bridges without a joint decision.

Stage 2: dbxForm and dbxReport

Both components receive more uniform state, request, definition and render storage. Existing behavior is maintained where it makes sense.

Phase 3: dbxComponent as a basic concept

A base class or a base train is only introduced when it is clear which common functions are really stable.

Phase 4: Workspace and Window Concept

openWin, dialogs, editor windows, reports and status areas become easy Workspace concept brought together. Not a heavy desktop copy.

Phase 5: Mobile/Tablet polish

Components get responsive rules and mobile operating logic. Native app connection remains optional via adapters.

Document status: 2026-04-29. This document is an architectural mission statement and not a backwards compatibility guarantee. It serves as a common decision basis for the new dbxapp version.