Non-Persistent Objects Validation
- 5 minutes to read
The Declare Validation Rules topic describes how to validate persistent object properties. However, non-persistent object can also be validated. These objects are not saved or deleted, so they cannot be validated in the Save or Delete context. The non-persistent object validation can be performed when executing a specific action (in Action context). This topic provides examples on how to validate non-persistent objects:
Validate Report Parameters
End-users can be required to specify report parameters when viewing reports with the filtered data source:
These parameters can be validated using the approach described below.
- Implement a ReportParametersObjectBase class descendant and set the report’s IReportDataV2.ParametersObjectType property to your custom type (see Data Filtering in Reports V2).
- Apply a validation rule to a required property. Set the rule’s custom validation context to “PreviewReport”. This can be done either in code, or in the Model Editor (see Declare Validation Rules).
- The validation of report parameters should be performed when executing the Preview action. So, navigate to the ActionDesign | Actions | PreviewReportV2 node in the Model Editor, and set the ValidationContexts property to “PreviewReport”.
The following snippet illustrates the ReportParametersObjectBase class descendant. Its ShowTasksAssignedTo property is decorated by RuleRequiredFieldAttribute.
[DomainComponent]
public class MyReportParametersObject : ReportParametersObjectBase {
public MyReportParametersObject(IObjectSpaceCreator provider) :
base(provider) { }
public override CriteriaOperator GetCriteria() {
return CriteriaOperator.Parse("[FullName] = '" + showTasksAssignedTo.FullName + "'");
}
public override SortProperty[] GetSorting() {
List<SortProperty> sorting = new List<SortProperty>();
return sorting.ToArray();
}
protected override IObjectSpace CreateObjectSpace() {
return objectSpaceCreator.CreateObjectSpace(typeof(Contact));
}
private Contact showTasksAssignedTo;
[RuleRequiredField("RuleRequiredField for MyReportParametersObject", "PreviewReport",
"Assigned To cannot be empty")]
public Contact ShowTasksAssignedTo {
get {
return showTasksAssignedTo;
}
set {
showTasksAssignedTo = value;
}
}
}
The following image illustrates the rule’s node in Model Editor.
The following image illustrates the broken rule detection.
Validate Password Complexity
The ChangePasswordByUser Action is accessible by end-users when the Standard Authentication type is used in an XAF application. By default, end-users have the ability to change their passwords and set simple or even empty passwords. However, the production environment can have strict security, and it may therefore be required to use only complex passwords. The solution is to validate a new password value when an end-user attempts to change a password.
The Change My Password dialog contains the ChangePasswordParameters Detail View.
The ChangePasswordParameters class is a non-persistent class, provided by the SecuritySystem module.
The NewPassword is a property to be validated. As this property is implemented in the Security module, the best way to validate it is to apply the rule via the Model Editor.
Important
Make sure that the Security module is added into the list of required in the Module Designer of the module where you perform this customization
Right-click the Validation | Rules node. Select Add… | RuleRegularExpression. Set new rule’s ID property to “Password is complex”. Set TargetType to “DevExpress.ExpressApp.Security.ChangePasswordParameters”, TargetPropertyName to “NewPassword”, TargetContextIDs to “ChangePassword” and SkipNullOrEmptyValues to “False”. Set the Pattern property to “
^(?=.*[a-zA-Z])(?=.*\d).{6,}$“. Only passwords consisting of 6 or more characters and digits match this regular expression. Replace the MessageTemplateMustMatchThe Pattern value to a user-friendly message describing password requirements. For instance, you can type “New password must consist of at least 6 characters and digits.”
Note
You can compose your own pattern to fit your password requirements. If you are not familiar with regular expressions, you can refer to the regexlib.com website to search an appropriate regular expression. If it is required to restrict empty password use, create the RuleRequiredField rule instead of RuleRegularExpression.
The Change Password dialog contains the OK button. This button is an Action that has the DialogOK ID. Navigate to ActionDesign | Actions | DialogOK and set the ValidationContexts property to “ChangePassword”. As a result, the “ChangePassword” validation context identifier will be associated with the DialogOK Action.
The Validation system is not fully initialized until a user has logged into the application. To initialize the Validation system, edit the Module.cs (Module.vb) file, override ModuleBase.Setup method and handle the XafApplication.SetupComplete event. In the event handler, access the Validation Module and call its ValidationModule.InitializeRuleSet method. This will ensure that you validation rules are checked in the “Change Password on First Logon” screen.
using DevExpress.ExpressApp.Validation;
//...
public override void Setup(XafApplication application) {
base.Setup(application);
application.SetupComplete += application_SetupComplete;
}
void application_SetupComplete(object sender, EventArgs e) {
ValidationModule module = ((XafApplication)sender).Modules.FindModule<ValidationModule>();
if (module != null) module.InitializeRuleSet();
}
Application administrators will still have the ability to assign an insecure password to a certain user via the ResetPassword Action. However, you can validate the ResetPasswordParameters.Password property using the approach described above.
The following window will be displayed when an end-user provides a new password not matching the complexity requirements.
