You can hide one class constraint from every relevant ViewModel when that constraint is not useful in a particular UI context; this page is for modelers who need to apply that opt-out consistently rather than editing each ViewModel by hand.
What this changes
A constraint is a rule on a model class. MDriven evaluates the constraint expression, and the constraint is broken when that expression evaluates to false. Constraints discovered for objects shown by a ViewModel are presented in the ViewModel by default.
For example, a Car constraint named MustHaveBrand may require that self.Brand is not empty. It is useful while editing a car, but may be noise in an overview ViewModel that lists many cars. Opting the constraint out prevents that constraint from being presented in the selected ViewModels. It does not remove the constraint from the model and does not change whether the rule is broken.
Constraint severity is defined on the constraint itself. Error, warning, and information constraints can be rendered differently by the UI. Opting out removes the selected constraint from the applicable ViewModel presentation regardless of its severity.
When to opt out a constraint across ViewModels
Use a bulk opt-out when all of the following are true:
- The rule belongs in the domain model and must remain defined as a class constraint.
- The same constraint is irrelevant or distracting in several ViewModels that expose the constrained class.
- You want to keep other constraints visible in those ViewModels.
For example, opt MustHaveBrand out of list and navigation views where the user cannot set the brand, while leaving it visible in the car-editing ViewModel.
Do not use this operation to disable a business rule. If the rule should no longer apply, change the constraint definition after reviewing its domain impact. To create feedback that belongs only to a particular input control or ViewModel, use ViewModel validations instead.
Apply the EAL bulk opt-out
Use the EAL code supplied for this operation to locate the relevant ViewModels and add the selected constraint to their constraint opt-out configuration.
- In MDriven Designer, identify the class constraint that you want to suppress. Record its exact constraint name.
- Define which ViewModels are relevant. Include only ViewModels that can discover the constraint because they show objects of the constrained class.
- Run the approved EAL expression against the model.
- Save the model.
- Open representative affected ViewModels and verify that the selected constraint is opted out while unrelated constraints remain available.
- Run the application and create or open an object that breaks the constraint. Confirm that the constraint is no longer shown in the opted-out ViewModels.
- Open a ViewModel where the constraint should remain visible and confirm that it is still presented there.
Important: The EAL expression for this operation is not present in the supplied source material. Do not substitute a guessed expression. Obtain the approved expression before running a bulk model change.
Verify the result in the ViewModel Editor
You can opt constraints out in an individual ViewModel in the ViewModel Editor. This is useful both for verification and for exceptions to the bulk decision.
- Open the ViewModel in MDriven Designer.
- Locate the constraints discovered from the classes used by that ViewModel.
- Move the selected constraint to the opt-out state.
- To show it again later, opt the constraint back in.
- Save, upload the model where applicable, and refresh the running application.
For example, after opting MustHaveBrand out of an AllCars ViewModel, a car with no brand can still break the constraint, but that message no longer appears in AllCars. In an EditCar ViewModel where the constraint remains opted in, the message still appears until the user assigns a brand.
Constraint opt-out and validation rules
| Mechanism | Use it for | Example |
|---|---|---|
| Class constraint | A domain rule that applies to instances of a class | A car must have a registration number. |
| Constraint opt-out | Hiding a class constraint in a ViewModel where its message is not relevant | Hide the registration-number message from a read-only list, but keep it in the edit ViewModel. |
| ViewModel validation rule | Feedback associated with controls in one ViewModel | Show a validation message on an input when its text is shorter than the required length. |
Avoid duplicating a constraint expression as a ViewModel validation rule. Where a ViewModel validation needs to reflect a class constraint, use the constraint's brokenness rather than maintaining the same expression in two places.
Scope and gotchas
- A constraint target attribute is information supplied by the constraint designer; a class constraint is not inherently limited to one UI attribute. Do not expect the target attribute alone to determine where a constraint is rendered.
- A bulk opt-out should be limited to ViewModels that actually expose the constrained class. Suppressing a constraint everywhere can hide useful editing feedback.
- Review new ViewModels after the bulk change. A later ViewModel that exposes the class may need its own opt-out decision.
- Action opt-out is a separate feature. Use Available Actions and Opting out actions to control action presentation.