Capability Families¶
When To Use It¶
Use capability interfaces when consumers should depend on what a VM can do rather than what concrete type it is. Capabilities are the additive behavior surface of VMx.
Shape And Ownership¶
The 22 capabilities are grouped by intent:
- selection and expansion verbs
- lifecycle verbs
- dialog and form verbs
- search, filter, and paging
- CRUD and current-item CRUD
- generic management
Capabilities never reshape the core hierarchy. A VM advertises only the verbs it actually supports.
Lifecycle And Messaging¶
Capabilities define contracts, not subscriptions. Any property-changed or message-hub side effects come from the implementing VM or helper, not from the interface itself.
The important rule is uniform across families: if a capability has a can_*
predicate, callers should respect it before invoking the verb.
Cross-Language Surface¶
Representative families:
| Family | Examples |
|---|---|
| Selection | ISelectable, IDeselectable, ISelectionTogglable |
| Expansion | IExpandable, ICollapsible, IExpansionTogglable |
| CRUD | INewCreatable, IDeletable<T>, IUpdatable<T>, ISavable<T> |
| Paging | IPageable |
The conceptual set is identical across flavors; only the identifier casing changes.
Example¶
Capability-aware consumers usually read like this in any flavor:
- show Select only when the VM is selectable
- show Expand only when the VM is expandable
- show Delete current only when the container exposes current-item delete
The Notes Workspace capability action bar is the concrete reference for this style of consumer.
Common Pitfalls¶
- Treating capabilities as inheritance roots instead of additive contracts.
- Collapsing granular verbs into a coarser abstraction and losing intent.
- Forgetting that core VM types do not implicitly implement every capability.