RAD Roadmap

1. Basic idea

dbxapp aims to bring the best of Borland, Concept16 and Visual DataFlex/4GL into a modern PHP-, JavaScript- and CSS-grosstime. Not as a nostalgic copy, but as a clear RAD system for data-driven business applications.

dbxapp remains dbxapp: server-side PHP runtime, DD, FD, templates, modules, Session/Remember State, Client Libs and myX inheritance.

2. LEGO instead of Puzzle

The architecture should not consist of special parts that fit in exactly one place. Each larger component should have the same basic connections. As a result, Building blocks are combined, replaced and extended.

dbx()->form('kunde')
dbx()->report('kunden')
dbx()->grid('kunden')
dbx()->dialog('delete')
dbx()->window('kunde')
dbx()->workflow('kunden-import')
dbx()->process('kunden-index')

All these building blocks should understand the same connection language:

id
context
dd
fd
tpl
data
state
request
actions
events / hooks
render
client
trace

3. Aim for module authors

Module code should remain technical. Even users with little programming experience should Can build applications when DD, FD and templates are prepared.

class kunden {
    public function list() {
        return dbx()->report('kunden')
            ->dd('kunde')
            ->fd('kunden|rpt-kunden')
            ->rowEdit()
            ->rowDelete()
            ->run();
    }

    public function edit() {
        return dbx()->form('kunde')
            ->dd('kunde')
            ->fd('kunden|frm-kunde')
            ->run();
    }
}

Minimum should also be possible:

return dbx()->report('kunden')->run();
return dbx()->form('kunde')->run();

In this case, dbxapp searches for clear, documented conventions. The trace shows afterwards, which DD, FD, templates and classes were actually used.

4. Adaptability without kernel change

Everything must remain adaptable, but the adjustment should run on clear levels:

1. DD: Data, fields, defaults, rules, rights, labels, UI metadata.
2. FD: concrete form/report/grid field view.
3. Templates: Presentation and layout.
4. Properties: simple component options such as Rows, Sort, Buttons, Mode.
5. Hooks: Targeted extension points without copying the component.
6. Module classes: Domain logic.
7. myX: System-wide inheritance for experts.

dbxForm   -> myForm
dbxReport -> myReport
dbxDB     -> myDB
dbxTPL    -> myTPL
dbxWebApp -> myWebApp

5. Component lifecycle

Form, Report, Grid, Dialogue, Window, Workflow and Process should in the long term be Predictable workflow. Today’s methods remain compatible but become internal oriented towards clearer steps.

construct
init_context
load_definition
load_state
read_request
validate
process
render
save_state
trace

forward init() and forward run() may be as The compatibility bridge remains. But the new structure should be clear about the basic lifecycle, parent: Protected hook methods.

6. Core standard behaviour

Many things that happen manually in modules today are to become official standard building blocks.

Modules may still contain special logic, but standard behavior should not be repeated We need to rewrite.

7. Workflow and Process

Workflows and processes are thought of separately. A workflow describes the domain process. A process describes the technical, resumable execution.

Workflow = fachlicher Ablauf
Process  = technische Ausfuehrung
Step     = einzelner Schritt
State    = gespeicherter Zustand

Workflows must not be static. They should respond smartly to state, errors, user decisions and rights.

upload -> preview -> validate
if valid: import
if invalid: mapping
if cancelled: cleanup
if error: retry_or_abort
summary

Processes for large amounts of data run in chunks:

State laden
Pause/Cancel pruefen
Chunk laden
Chunk verarbeiten
Fortschritt speichern
Status zurueckgeben
naechster Tick

8. Persistent process state

A process such as editing 100000 records must be completed after browser closure or interruption. The last secure state is stored permanently.

dbxProcess
  id
  process_key
  workflow_key
  user_id
  modul
  component_id
  status
  current_step
  cursor
  processed_count
  total_count
  payload_json
  result_json
  error_json
  pause_requested
  cancel_requested
  started_at
  updated_at
  finished_at

Status values:

new
running
paused
cancel_requested
cancelled
done
error
interrupted

If 53589 of 100000 records have been processed, dbxapp must be reopened find the process, view the progress and continue from the next secure record.

9. Restoring UI-State

Not only processes, but also normal working conditions should become recoverable:

• Active module
• Active workflow
• Open windows and dialogues
• Active tabs
• Report page, search, sorting, selection
• Form-RID and form values not yet saved
• Grid filter, selection, scroll/cursorstand as appropriate
• ongoing, paused or faulty processes

When the app is launched, dbxapp should detect open work and offer a clear recovery option.

10. Roadmap

11. Pilot findings from current modules

• myLKW Shows need for action dispatchers, process state, JSON endpoints, grid sync and domain actions.
• myLKW list Shows need for official grid component with read/sort/save/delete/sync.
• myLKW report shows a need for special report hooks instead of direct internals.
• dbxUser admin Shows typical admin reports with row/multi-actions, modal, search and pagination.
• dbxContent edit Shows standard form flow and Observer/Wait-Pattern.

12. Golden Rules

Ein Modulautor soll dbxapp benutzen, nicht dbxapp nachbauen.

Wenn ein Modul technischen Standardcode enthaelt,
fehlt wahrscheinlich ein Baustein im Kern.

Der Browser ist Anzeige und Steuerpult, nicht die Wahrheit.

Der letzte sichere Stand muss serverseitig gespeichert sein.

Kein Fachproblem darf eine Kernel-Aenderung erzwingen.

Konventionen sind erlaubt, aber immer tracebar.

Bestehende Module bleiben kompatibel, neue Module folgen der neuen Methodik.