Design fundamentals

Reference status: 2026-07-26

dbxapp separates technical logic, content and presentation. One Design is a complete application shell with its own HTML, CSS, JavaScript and images. One Skin is a color and contrast variation within a design. This separation allows technically identical sides with very different appearances.

There are currently three independent frontend designs:

The configured admin design is dbxapp. A frontend user may change the frontend design. If the horizontal admin menu is displayed in the frontend for administrators, it remains explicitly horizontal and does not replace the vertical Flowers navigation.

Concepts and responsibility

Design

One design is responsible for:

• the outer HTML structure of the side,
• Main and admin navigation,
• header, content surface, footer and window dock,
• responsive behaviour;
• typography, abstractions, surfaces and imagery,
• design-related JavaScript additions,
• the integration of the offered skins.

A design is responsible not:

• shop, CMS or user logic,
• data access and rights verification,
• storing forms,
• report pagination or ajax transport,
• the technical meaning of a module.

Skin

A skin changes within a design above all colors, contrasts, shadows, frames and light / dark behavior. The skin must not rebuild the basic structure of a design. If navigation, columns or page shells are to be different, a separate design is the right level.

Module design

Modules may bring their own component CSS and their own templates, for example:

This module design only designs the domain edition. The surrounding side continues to come from the active global design under dbx/design/.

List of a special design

One design is under:

htm/default.htm is the prerequisite for a directory to be recognized as a publicly selectable frontend design. Lists with a name that has _ or - starts, are not offered in the design selection.

Each design should own all design-related files themselves. Flowers CSS, images or JavaScript from dbxapp inheritance. Only centralized system and vendor resources are shared, such as Bootstrap, Bootstrap Icons, jQuery and dbx/js/lib/core.js.

Design templates and page variants

The page shell is filled with dbxTPL::get_design_tpl() loaded. The starting point is the active combination of:

• dbx design: design package,
• dbx page: side variant,
• dbx lng: language,
• dbx color: Skin.

Typical files in the design are:

If a requested page variant does not exist in the active design, the template resolution is conspicuous default.htm back. The current window mechanism uses dbx_window=1 to select the window page variant. A separate adminWin-Variant is not implemented in the current state and must therefore not be assumed.

A minimal default.htm contains at least:

The real content marker is [dbx:content. The markers {dbx:skin css, {dbx:skin class, {dbx:design, {dbx:color and {dbx:lng by: dbxTPL replaced.

Optionally, a design shell may contain reusable fragments:

The content is in the same design htm/logo.htm, htm/branding.htm and htm/footer.htm. dbxTPL It only uses actually used slots. Existing designs without slots remain unchanged.

Duration: How a design is determined

The process is centrally located in dbxWebApp:

1. check remember() Reading dbx design, dbx color, dbx lng and dbx edit Remember-State and Request.
2. Request values may overwrite the recorded values.
3. check design() Validates the design and removes the alignments User and admin against the configuration.
4. An admin module with admin in the module name switches for administrators default design admin.
5. design load() selects design and page, sets the module content in [dbx:content Enter and deliver the finished page.
6. In dbx ajax=1 no new page shell is loaded; Only the module content is returned.

The default values are in dbx/modules/dbx/cfg/config.php:

A module or admin tool can be used for its call dbx page, dbx design, dbx lng and dbx color set. Such switches shall be made before loading the design shell and shall not circumvent central validation.

Frontend and administration

The current separation is:

• Normal frontend pages use the design chosen by the user.
• dbxShop is a frontend module and therefore runs in the active frontend shell.
• Modules with the Suffix admin, for example dbxShop adminFor administrators, switch to the configured admin design.
• The admin menu can also appear in the frontend for logged-in administrators. In the Flowers design, it is output as its own horizontal strip above the actual frontend header.
• One by Ajax or OpenWin loaded content does not automatically receive a second complete design. The window shell comes from the calling context; Components of the admin content are designed by their module styles.

This allows the frontend and backend to remain visually separable without duplicating module code or requiring an iframe. If later real design isolation in windows is needed, it must be implemented as its own documented window mode.

Design and skin selection in the menu

The selection is in the main menu template:

dbxMenu::frontend_design_options() Searched at runtime dbx/design/*/htm/default.htm. This will make a new full design appear without a hardwired list in the menu. Within the selection forms dbxMenu::render_design_skin_menu() A separate group for each design. These include only its own color variants.

The binding skin recognition is centrally located in dbxApi::get_design_skin_ids(). It reads the existing files for each design:

So there is no second skin list in dbxMenu or utilities.js. A new file such as skin-petrol.css is automatically offered only in the group of the relevant design. dbxApi::normalize_skin() Test dbx color against exactly this catalogue, so that no non-existent style sheet is selected.

Each selection is a normal, copyable GET call with dbx design and dbx color. Thus, design change and pure color change execute the same server-side validated sequence; JavaScript is not required for selection. utilities.js retained applySkin() for programmatic surfaces and stores such local selections per design. The color of one design no longer accidentally overwrites the selection of another design.

CSS layers

A robust division is:

Skins should preferably overwrite CSS variables. Components access these variables. As a result, a dark variant does not have to copy the entire component library.

In design dbxapp shall be: glass-3d.css after base.css and theme.css involved. The file designs the existing components via the skin tokens and therefore must not introduce its own color world separate from the skin.

Mandatory structural classes

The HTML structure is uniform throughout the system, the visual design remains independent for each design. dbxTPL, dbxForm and dbxReport They produce the same semantic classes:

A variant always complements the base class, for example class="dbx-bar dbx-bar-module". JavaScript uses domain data dbx *attributes and no representation class as a behavior anchor. Old parallel terms for module, editor or toolbar bars are not allowed. A design may fully determine colors, distances, typography and effects, but must support this structural contract. As a result, templates, forms and reports remain predictable without making designs dependent on each other.

The Flowers Design

Flowers is deliberately not a color copy of dbxapp. Its characteristics are:

• solid, i.e. left-hand main navigation,
• wood, plant and copper appearance,
• organic ornaments and floral icons,
• an independent top bar and its own footer,
• a horizontal admin strip for administrators,
• independent login styling,
• Light and dark skin,
• design-related behaviour in dbx/design/flowers/js/flowers.js.

The left navigation must remain scrollable with long or unfolded submenus. drop-downs of the horizontal admin menu must be above the page contents; Stacking is context and z index Part of the design check.

Creating a new design

For administrators, the preferred way is the Design Studio:

The wizard generates an independent copy, queries division, menu form, footer, branding, logo, colors and typography and validates the contract before activation. The manual path remains possible for developers:

1. Choose a unique, URL-compatible name.
2. Underground dbx/design/{Name at least htm, CSS, js and img Create.
3. A complete htm/default.htm with [dbx:contentmenus, footers, vendor dependencies, and core.js create.
4. Own colors.css, base.css, theme.css Create skin files.
5. Needed c-*.css and menu rules in the design itself.
6. Test the design with guest, user and administrator.
7. Test long main and submenus, small displays and keyboard operation.
8. Check forms, reports, CMS, login, shop and OpenWin/Ajax.
9. Only then the design over dbx design ={Name Offering productionly.

Checklist

• htm/default.htm exists and contains [dbx:content.
• {dbx:skin css and {dbx:skin class are involved.
• Body Carried data dbx design and data-dbx-skin.
• core.js?design ={dbx:design is loaded.
• The design does not import private files of another design.
• The main and admin menu are accessible and cover the content correctly.
• Submenus remain accessible at low altitude.
• Light/Dark or All skins offered work without unreadable contrasts.
• Login, CMS, shop, forms, reports, windows and Ajax were checked.
• Admin modules run in admin design; Frontend pages remain switchable.

Related documentation

• Design AI reference
• Design Studio and AI Wizard
• Routing, Templates and Module Inclusion
• dbxTPL Guide
• JavaScript system libs
• Mandatory rules for AI agents