You use ViewModels in an OCL expression to create a checked reference to a ViewModel on a model class, for authors who open, test access to, or otherwise supply a ViewModel from an expression.
What ViewModels returns
<ClassName>.ViewModels returns a tuple containing the ViewModels defined for that class. Select a member of that tuple by its ViewModel name.
<ClassName>.ViewModels.<ViewModelName>
For example, the following expression refers to the OrderSummary ViewModel on Customer:
Customer.ViewModels.OrderSummary
Use this reference when another OCL operator expects a ViewModel name or ViewModel argument. It makes the dependency visible to MDriven Designer validation.
Use a checked ViewModel reference
When you need to supply a ViewModel in an expression:
- Identify the model class that owns the ViewModel. In this example, it is
Customer. - In the expression, enter the class name followed by
.ViewModels.. - Select or enter the required ViewModel member, such as
OrderSummary. - Use the resulting reference as the argument required by the operator.
For example, to open a document report with the OrderSummary ViewModel:
self.opendocumentreportshow(Customer.ViewModels.OrderSummary)
The exact operation determines how the ViewModel is used. The important part is that Customer.ViewModels.OrderSummary is a model-checked reference, not a hand-written name.
Why not use a string?
Do not pass a ViewModel name as a literal string when a ViewModels reference is accepted.
| Approach | Example | Result when the ViewModel is renamed |
|---|---|---|
| Checked reference | Customer.ViewModels.OrderSummary
|
Model validation identifies the broken reference and shows an error. |
| Literal string | 'OrderSummary'
|
The expression has no checked dependency on the renamed ViewModel and can retain an outdated name. |
For example, if OrderSummary is renamed to CustomerOrderSummary, an expression that contains:
Customer.ViewModels.OrderSummary
becomes invalid. MDriven Designer model validation reports the error, so you can find the expression and update it to:
Customer.ViewModels.CustomerOrderSummary
This feedback is the reason to use ViewModels wherever a ViewModel name is required.
Example: check access to a ViewModel
The canAccess operator checks whether an object can access a ViewModel according to that ViewModel's Access Expression settings. Supply the ViewModel through ViewModels:
self.canAccess(Customer.ViewModels.OrderSummary)
If OrderSummary is renamed, validation also identifies this usage. See Documentation:OCLOperators canAccess for the access-check behavior.
ViewModels and the current ViewModel
ViewModels identifies a ViewModel defined on a class. It does not describe the ViewModel currently being evaluated. To obtain the name of the active ViewModel from within its context, use ViewModelName.
For the structure and purposes of rooted and unrooted ViewModels, see Documentation:ViewModel. For context variables such as self and vCurrent_<ViewModelClass>, see Documentation:How to use vCurrent and âselfâ correctly in viewmodels.
