You can configure a ViewModel to save edited field values automatically, which is useful for mobile-oriented pages where users should not need a Save button.
By default, a MDriven application uses a Save button. This gives the user a desktop-style editing workflow: make several changes, then save them, cancel them, or use undo and redo where applicable. Automatic saving changes that workflow. When a field update reaches the server, its changed value is saved rather than waiting for the user to select Save.
Choose an autosave strategy
| Strategy | Use it when | Result |
|---|---|---|
| ViewModel tagged value | Field edits should be saved as they are sent from the client to the server. | Field values are autosaved. Actions still need their own save behavior. |
| Periodic action | You need a delayed or controlled save schedule. | A repeating action checks whether the current ViewModel has unsaved changes and saves only when it is dirty. |
Recommended: enable autosave on the ViewModel
Use the Span.Eco.AutoSave tagged value on the whole ViewModel.
- Open the ViewModel for the page in MDriven Designer.
- Add the
Span.Eco.AutoSavetagged value to the ViewModel. - Test an ordinary field edit in the running application. For example, change a person's name and move focus away from the field; when the client sends that update to the server, the changed field value is saved.
- Test every action on the page separately. Configure actions that change data to save as part of the action, because the ViewModel autosave setting applies to values sent from fields; it does not make every action save automatically.
Important scope of Span.Eco.AutoSave
Span.Eco.AutoSave means that data changes from fields are automatically saved as soon as they travel from client to server. It does not mean that all possible changes in the ViewModel are automatically saved.
For example, if an action creates or changes data, make that action save its changes. The underlying save operation is Save, expressed in OCL as selfVM.Save. selfVM is the current ViewModel; see SelfVM.
Do not assume that autosave removes the need to design the persistence point for dialogs, modals, and actions. In particular, decide whether a modal's edits should be committed immediately or remain part of the normal Save/Cancel workflow, then test that flow.
Alternative: save periodically when data is dirty
Use a periodic action when you need a controlled interval instead of saving each field update. Configure the periodic action to repeat at a suitable interval, for example every 2000 ms, and prevent it from running unless the ViewModel has unsaved changes.
- Create a periodic action for the page.
- Set its repeat interval. A value such as 2000 ms checks approximately every two seconds.
- Set the action's DisableExpression to
not selfVM.IsDirty. This disables the action while there are no unsaved changes. - Use the following expression as the action behavior:
selfVM.IsDirty.whenTrue(selfVM.Save)IsDirty indicates that the current ViewModel has changes waiting to be saved. The whenTrue expression ensures that selfVM.Save runs only when there is dirty data.
For example, a user can edit several fields during the two-second interval. At the next periodic run, the action saves the accumulated changes if the ViewModel is dirty. If nothing has changed, the DisableExpression keeps the periodic action from running.
Design the user experience deliberately
Autosave is appropriate when an edit is intended to be accepted without an explicit confirmation step, such as a focused mobile workflow. It is less suitable when users need to assemble several related changes, review them, and then choose Save or Cancel.
Be explicit in the page design when different areas use different save behavior. A user who sees neither a Save button nor a clear indication that edits are saved automatically may not know whether a change has persisted. If the timing matters, provide a clear page-specific indication or a way to explicitly save.
Automatic saving can also increase database traffic because frequent field updates can lead to frequent saves. This is particularly relevant when changes are recorded as history: slow typing can result in multiple recorded updates. Use a periodic action when delaying and grouping edits is a better fit.
Keep the standard save workflow when needed
If the page needs explicit Save, Cancel, Undo, or Redo behavior, use the standard actions rather than autosave. Standard actions describes how to ensure that the default Save, Cancel, Refresh, Undo, and Redo actions exist.
Do not hide the normal Save affordance until you have verified that all page edits and relevant actions follow the intended autosave behavior. A page that combines autosaved fields with unsaved action results is confusing and risks losing user changes.