Current User: Page Data Binding

Introduction

This tour focuses on the page-level current-user binding pattern in Demo Projects HQ. Unlike the shared layout flow, which injects current_user into EJS locals before render, this page declares a dedicated dmx-serverconnect component so App Connect can reuse the signed-in account at runtime. That is the practical pattern to learn when you want to assign a Server Connect URL in the page and then use its returned data directly in bindings.

Assign the URL on the page

`sc_current_user_api` points to `/api/auth/current_user`, so the page has a runtime source for the signed-in account.

Read the returned data path

The action response key `current_user` becomes `sc_current_user_api.data.current_user` in App Connect.

Use it in a real guardrail

The page compares the signed-in account against the edited record before it shows the delete form.

Select the page-level current-user component

Inspect where `/api/auth/current_user` is assigned

Follow the binding into the delete-form visibility rule

The page declares a dedicated current-user request

In App Structure, this page keeps its runtime data sources explicit. sc_user loads the user record being edited, while sc_current_user_api loads the signed-in account. Selecting sc_current_user_api makes it clear that current-user data is not being guessed from the form or from a custom script.

Properties shows the selected request component

Once sc_current_user_api is selected, the Properties panel becomes the main reading surface for this workflow. Use the wider panel first so the URL control and returned data path make sense in context instead of looking like an isolated field.

The Server Connect URL is assigned on the component

This is where the page-level request is configured. In the Properties panel, you can see that the component points to /api/auth/current_user, so when the page runs, App Connect receives the action response under the component id. Because the JSON action returns a current_user object, the binding path on the page becomes sc_current_user_api.data.current_user.

<dmx-serverconnect id="sc_current_user_api" url="/api/auth/current_user"></dmx-serverconnect>

A page element consumes that current-user data

With the delete form selected, the Properties panel is the clearest place to understand where the page-level guardrail lives. The form does not need its own request because it can bind against the already-loaded sc_current_user_api component. That keeps the rule visible on the exact element whose availability depends on the signed-in account.

The show expression compares two identities

This dmx-show expression is the whole binding payoff. sc_user.data.user.id is the record currently being edited. sc_current_user_api.data.current_user.id is the signed-in account loaded from /api/auth/current_user. When both ids match, the delete form stays hidden so the current user cannot remove the account they are actively using.

important: This is a UI guardrail. The secure delete action still needs server-side permission checks.

<form id="user_delete" is="dmx-serverconnect-form" method="post" action="/api/users/delete" dmx-show="sc_user.data.user.id != sc_current_user_api.data.current_user.id">
  ...
</form>

Next steps

Demo Projects HQ uses the same current-user source in two different layers: the shared layout loads it server-side for EJS, and individual pages can load it again with dmx-serverconnect when runtime bindings need it. The important habit is to keep the request source explicit, keep the binding readable, and keep server-side security authoritative.

Assign the action URL on a page-level data component

Read values back through `componentId.data.responseKey`

Use current-user data for clear runtime guardrails, not as a replacement for server-side security