Skip to content

Conference App: create the client

Create the client from the current Foundation – WebAssembly Drilldown template, then add the Dashboard route used by this tutorial.

Before you begin: Complete Conference App tutorial.

Step 1 — Create the current template baseline

Follow the WebAssembly project steps. Create a TechStack workspace, choose Foundation – WebAssembly Drilldown, and name it ConferenceApp.

Keep the wizard-created AppHtml, index.html, virtual-directory registration, package-managed files, SQLite connection objects, including the built-in cDbSqliteDriver, managed host bootstrap, configuration, runtime includes, theme, drill-down style, history mode, view stack, and generated dashboard.

Do not rename the generated application identity. Leave the generated oWebAssemblyApp object, generated psApplicationTitle, source-level Set phoDefaultView to oDashboard, and Welcome tile unchanged. The generated host bootstrap and source/config identity already belong together.

Press F5 once. The dashboard opens in a browser and the Output panel identifies a +wasm-32 toolchain.

Checkpoint: Generated dashboard opens before source changes.

Step 2 — Add the Dashboard menu item

Add one menu object inside the existing oViewMenu. This gives users a stable Dashboard route from the application menu; the generated View menu does not provide that route for this tutorial.

Object oDashboardItem1 is a cWebMenuItem
    Set psCaption to "Dashboard"

    WebRegisterPath ntNavigateBegin oDashboard

    Procedure OnClick
        Forward Send OnClick
            Send NavigatePath
    End_Procedure
End_Object

Do not change Dashboard.wo: the generated Welcome tile remains the first dashboard tile, and the application keeps its generated default view.

Checkpoint: Press F5. The generated dashboard opens, and Dashboard in the application menu navigates back to it.

Reflection — Understand the generated data path

Before adding Presenter, pause and trace what the wizard already supplies. A WebAssembly WebAppClient runs its DataFlex application in the browser, so menu logic, view logic, and local data operations run on-device. The browser-hosted client contacts a server for data, not for every button click.

The template's SQLite connection

The generated ConferenceApp.src already connects the client to SQLite. The connection manager owns the logical connection, and the child driver object selects the SQLite adapter:

Use Db\cDbConnectionManager.pkg
Use Db\cDbSqliteDriver.pkg

Define C_SQLiteDb for "/dev/idbfs/MyAppData.db"

Object oConnections is a cDbConnectionManager
    Object oSqliteConn is a cDbSqliteDriver
        Set psConnectionId to "conf_data"
        Set psConnectionUri to ("sqlite:" + C_SQLiteDb + "?mode=rwc")
    End_Object
End_Object

conf_data is a logical connection ID, not a filename. The connection manager maps that ID to the sqlite: URI and the built-in cDbSqliteDriver. The URI's sqlite: scheme selects the driver, while mode=rwc opens the database for reading and writing and creates it when needed.

/dev/idbfs/ is the browser-side filesystem namespace used by this WebAssembly client. The SQLite driver and runtime manage the on-device database there; do not create or copy the .db file manually. The SQLite driver reference and WebAssembly runtime walkthrough describe the two sides of this behavior: database adapter selection and browser-local execution/storage.

From file lists to entities and Data Dictionaries

If you are coming from DataFlex Windows, think of an Entity as the source-defined description of a persistent table: fields, indexes, relations, and its connection metadata. It replaces the filelist/FD-oriented model for TechStack data. A cDataDictionary subclass attaches to that entity and owns its local record buffer, validation rules, finds, saves, and deletes.

On the next page, PresenterDataDictionary.pkg declares Entity Presenter with { Connection=conf_data }; its cPresenterDataDictionary class sets phEntity to RefEntity(Presenter). That is the model-to-DDO link. The full entity, field, index, and validation code appears in Add local Presenter data.

The Connection attribute repeats the same conf_data ID used by oSqliteConn. It does not name the driver directly and it does not contain a path. The Data Dictionary adapter asks the connection manager for that ID, receives the SQLite driver, and sends database operations through it.

How Data Dictionary binding works

The oPresenterDD object created in CreateAndSyncDB.pkg is a Data Dictionary Object (DDO). It is the bridge between data model and UI:

Object oPresenterDD is a cPresenterDataDictionary
End_Object

Set Main_DD to oPresenterDD
Set Server to oPresenterDD

// Inside a data-aware control:
Entry_Item oPresenterDD.FirstName

Main_DD and Server tell a view which DDO supplies its records. Entry_Item oPresenterDD.FirstName binds a form or column to the DDO's local buffer; it does not read a global Presenter.FirstName buffer. The Data Binding reference shows this object-first binding model.

The complete data flow

The tutorial keeps these responsibilities separate:

REST JSON
    ↓
cHttpClient
    ↓
Presenter[] / Room[] / Presentation[]
    ↓
UpdateAllFields on a Data Dictionary
    ↓
Request_Save / SaveRecord
    ↓
cDbSqliteDriver
    ↓
/dev/idbfs/MyAppData.db

The Presenter page defines the entity and DDO, then calls CreateDatabase to create local storage. The synchronization page downloads JSON with cHttpClient, fills DDO buffers, and saves them through the driver inside a transaction. The complete-application page adds related entities and parent DDOs with Set DDO_Server; the search page adds constraints to the Presentation DDO, and the bound list displays the constrained buffer.

Views provide interaction. Data Dictionaries hold local records and enforce rules. The SQLite driver persists those records on the device. cHttpClient is needed only when the application synchronizes with the REST service. This separation is what makes the sample both a WebAssembly application and a local-first, offline-capable application.

Next

Add local Presenter data.