EEZ Studio DynamicCallAction: Treat the Action Name as a Restricted Dispatch Key

EEZ Studio DynamicCallAction selects a User action using a string. That is useful for a small Dashboard dispatcher, but it does not turn every User action into a general function with arbitrary typed arguments and return ports.

The DynamicCallAction guide limits eligible actions to the Start/End form without user-defined inputs or outputs. The pinned editor action implementation shows the runtime lookup: evaluate an action-name string, find its index in assetsMap.actionFlowIndexes, and report an error if that name is absent.

The inspected version is EEZ Studio v0.29.0 editor commit 3000161d09d40a5c1dc2477ddc30b38037b3a612. The scope here is Dashboard dispatch through this component, not an assumed native function-pointer interface.

Treat the name as a dispatch key

A useful application design starts with a small explicit set of operations. For example, an operator may choose a harmless diagnostic summary or a reset of a temporary display filter. The application maps those choices to the exact eligible action names.

That map is an application-owned decision. DynamicCallAction performs its registry lookup, but the inspected execute function is not a policy engine that determines whether an operator should be allowed to invoke every registered action.

Avoid accepting an arbitrary remote string and passing it through solely because it names an existing action. Existence and permission are different checks. A restricted mapping also makes a later action rename visible in one place rather than spreading literal names throughout unrelated controls.

A missing name is an error case, not a fallback

The implementation checks that the evaluated action name is a string. It then looks up the name and rejects an undefined result before invoking executeCallAction. The source does not establish an automatic default action for misspellings or names removed from the build.

Design that failure path deliberately. A missing dispatch key might indicate an outdated application mapping, an unsupported operation or a mismatched project revision. Quietly substituting another action could perform the wrong operation while making the original defect harder to see.

For a diagnostic, make the selected logical operation, resolved action name and error outcome separately observable. Use synthetic operation identifiers rather than private user data. The purpose is to identify the failed mapping, not to print an entire request payload into a general log.

If a renamed action is part of the change, review the dispatch map and the built action inventory together. A successful editor rename does not, by itself, prove that every dynamically constructed string has been updated.

Respect the documented action shape

The documentation's no-input/no-output restriction matters even if ordinary static User action calls in the same project support data connectors. Do not infer dynamic argument forwarding from the static calling interface or from the presence of custom-input machinery elsewhere in the editor.

If an operation requires request data, first decide whether the selected EEZ version exposes a supported calling mechanism with the required contract. A static call can be clearer when the alternatives are known at design time and their signatures differ.

An application that deliberately uses shared state as a request context must give that state an ownership rule. The action-name lookup does not serialize concurrent callers, create a private snapshot or keep one request from replacing another's values. Those are separate design obligations, not features implied by dynamic dispatch.

Keep this distinction visible in the diagram: selecting which action runs is one decision; supplying coherent data and establishing when the operation is complete are others. Combining them under one label such as invoke can hide unsupported assumptions.

Test the registry boundary with two tiny actions

Create two eligible Start/End actions whose only effect is an unmistakable diagnostic marker. Add an explicit mapping from two application choices to their exact names. Exercise each choice and confirm that only the intended marker appears.

Next, use an unknown name through the diagnostic path and observe the supported error route. Then try an application choice that the mapping intentionally does not allow. That rejection should occur before the component is asked to dispatch; it tests the application policy rather than the registry lookup.

Finally, rename one action in a disposable copy while leaving the mapping unchanged. The resulting mismatch is a useful acceptance fixture for detecting stale dispatch strings. Repair the mapping deliberately and repeat the intended operation.

No Dashboard action was executed for this article. The source and documentation establish a bounded mechanism: a string selects an eligible registered action, with an error for a missing name. A reliable application keeps that key space small, respects the documented action shape and handles data ownership separately instead of assuming a general reflective function-call system.