JavaScript

dbxapp-JavaScript is a declarative extension of server-side pipelines. core.js detects required features, loads them and re-initializes them even after a HTML Ajax replacement.

The full interaction with a module is under Mandatory module manual.

Basic contract

An existing system capability is not fetch(), window.confirm(), a second modal or direct browser storage.

Language in the browser

General framework texts such as “Ja/Nein/Abbrechen“, sorting states” or technical runtime errors are centralized with dbx.translate(key, fallback) Dissolved from active language. Technical texts, on the other hand, remain the property of the language-dependent FD and are used on the server side in HTML or data attributes:

So there are exactly two clear levels:

• central JavaScript translation for generic controls of the libs;
• active FD for form, report and technical reports of a module.

Module JavaScript does not have its own third translation table for the same form texts.

Feature scope and automatic initialization

Features are registered on a root:

The scope is the root element and its children. A nested feature does not accidentally process elements of a neighboring module. Initialized after Ajax core.js only the newly deployed area again.

Use form and report templates {i} in IDs:

Thus, several instances of the same route remain separate from each other.

Ajax: HTML is the standard

One form:

A link:

Canon attributes:

Existing alt attributes such as Data target or data-replace remain compatible in existing modules. The new templates should data-ajax*Use names because purpose and affiliation are unique.

dbx ajax=1 It is not written in normal links. Only ajax.js sets the Ajax context of the request it executes.

Normal request remains functional

Ajax is progressive improvement:

1. The link has a real href.
2. The form must contain: Action, method And a real submit button.
3. The server can render the same route completely.
4. Ajax replaces only the appropriate partial view.

A module action must not only work if a JavaScript event handler has been executed.

Confirm: Declarative standard

Important attributes:

When “Yes” is set confirm.js the original link, button or form action continues automatically. is the same source as dbxAjax marked, the Ajax path is used first; Otherwise, the normal browser path will follow.

Confirm does not perform a mutation and is not a safety check. Rights, validation and, for mutating GETs, the action tokens are checked on the server side.

Confirm and Ajax: Sequence

The module should not replicate this order with its own click handlers. In particular, Confirm and openWin may not independently process the same click.

Programmatic Confirm

Only if the declarative continuation is not sufficient:

The Promise delivers yes, No, Cancel or close. Here, too, the domain mutations belongs on the server. Own dialogue DOM structures are not required.

JSON-Ajax

HTML is suitable for dbxForm and dbxReportBecause both return complete partial views. JSON is suitable for limited status or API actions:

JSON and HTML routes have different response contracts. A JSON route does not render a form template. A normal Form/Report Ajax does not provide an arbitrary mixed response.

core.js and UI state

Direct access to: localStorage or sessionStorage outside of core.js is prohibited. Only the central state can control namespaces, compatibility and cleanup system-wide.

report.js, form.js and grid.js

report.js assumes:

• Pagination ajax;
• single and multiple selection;
• reporting actions;
• Selection state and reload.

form.js assumes:

• Form state;
• Submit mechanics and field interaction;
• Reinitialization to Ajax.

grid.js assumes:

• Tab/grid output;
• column widths and visibility;
• Inline Edit and Grid Reload;
• UI state over core.js.

Domain modules complement configuration and subject endpoints, not the base pipeline.

Other system libraries

The CMS modules shall be: dbx.cmsRuntime registered. Only the core necessary for each processing and the page controller are initially loaded. A feature module shall not build a second Ajax, window, layer or editor infrastructure; Requests run over ajax.jswindow over openWin.js and joint helpers are obtained from the runtime context. The browser cache reduces repeated transmission, but lazy loading also saves parse, initialization and event costs for unused functions.

Binding rules

1. Use existing lib, not a second implementation.
2. Limit the feature to the smallest meaningful root.
3. {i} and use unique targets for repeatable components.
4. Genuine href-/ActionReceive fallbacks.
5. Use HTML as the default response for form and report.
6. Treat Confirm only as a user interaction.
7. Eligibility, validation and mutation can only be decided on the server side.
8. dbx ajax Do not manually build into normal URLs.
9. JavaScript must be repeatable initializable after an Ajax replacement.
10. Avoid direct browser storage.

Minimum tests

• Link/Formular without JavaScript;
• the same sequence with Ajax;
• correct and missing target;
• two instances of the same component;
• Confirm “Yes”, “No”, Escape and Close;
• no request for "no";
• Exactly one request at “Yes”;
• invalid rights or tokens are rejected on the server side;
• Renewed feature function after a target replacement.

Further chapters

• Mandatory module manual
• dbxForm
• dbxReport
• Security, integrity and performance