Validate Rules versus Edit Validate Rules
Is someone able to help me better distinguish the differences between these two?
Thank you,
oh goodie - another stab at a real-world example :)
A validate rule confirms the data entered meets certain specified conditions, and are only ever used w/ user input.
An edit validate rule confirms the data entered is in the correct format, and are only ever used on a property rule. OK, technically, edit validate rules can also be used in validate rules, but let's keep it simple for now.
As an example, you want to reserve a week at my luxurious Vrbo.
On my booking form, I would use a Validate Booking Dates rule to confirm the check-in date is before the check-out date, or the check-out date is after the check-in date, or that the check-in date is not any earlier than the current date. So, do the dates you entered meet certain specified conditions.
I would use an Edit Validate rule to ensure the dates you entered are in the proper format (mm/dd/yyyy or something like that). I do not want you to be able to enter an email address or a plain text message.
In my example, the Edit Validate rule would fire first checking to make sure you entered properly formatted dates - as you entered each date. Then, with valid date values, the Validate rule would fire to make sure you did not mangle your check-in check-out dates.
eddie
Dear Eddy,
I am struggling with the same question when reading through the online course material of BAE. The examples and descriptions you give here make sense to me, but seem in contrast or at least confounding with the other options described in "Methods of data validation"
The course says:
Properties > Selecting the appropriate property type ensures that users enter a valid value. And as an example "date" is given.
Controls > using a calendar control ensures that users enter a date value
and now you explain...->
Edit validation rules > An edit validate rule confirms the data entered is in the correct format
Dear Eddy,
I am struggling with the same question when reading through the online course material of BAE. The examples and descriptions you give here make sense to me, but seem in contrast or at least confounding with the other options described in "Methods of data validation"
The course says:
Properties > Selecting the appropriate property type ensures that users enter a valid value. And as an example "date" is given.
Controls > using a calendar control ensures that users enter a date value
and now you explain...->
Edit validation rules > An edit validate rule confirms the data entered is in the correct format
It seems all of the above above can check for correct format? But... maybe controls and properties are restricted to what's predefined by pega.... but maybe edit validation rules are more flexible, e.g. you can define them yourself stating that you want an @ in your text field when asking for e-mail-adresses? And only validation rule tests for more complex conditions?
Could you give a more in depth explanation disentangling properties, controls and validation rules?
Thanks.
Properties are containers for data. The type of the container dictates the content that the property can store. For example, you can create a text property or an integer property, or a decimal property, or a date/time property. If you attempt to use a property to store data that doesn't match the type, Pega Platform returns an error.
- Text is the most permissive property type, which makes text values tricky to validate. For example, Pega processes text values left-to-right, based on the character value. So you might see a list that sorts 273 before 41 before 7, because 2 < 4 < 7. (This is standard text processing for just about any programming language, and even an Excel worksheet. Most users immediately see something wrong with that ordering, because they assume that the values are numbers, but applications aren't as intuitive.)
- Integers only accept whole numbers. So 7 would be valid, but 3.1 would return an error. (3.1 is a decimal value, not an integer value.)
- Date/time properties specifically handle dates and times, which have very specific rules for performing any operations. For example, what does it mean to add "5" to a date/time value? 5 months? 5 days? 5 minutes?
Let's day you want the user to enter the date of an appointment. If the property is a text property, any of the following would be acceptable input:
Properties are containers for data. The type of the container dictates the content that the property can store. For example, you can create a text property or an integer property, or a decimal property, or a date/time property. If you attempt to use a property to store data that doesn't match the type, Pega Platform returns an error.
- Text is the most permissive property type, which makes text values tricky to validate. For example, Pega processes text values left-to-right, based on the character value. So you might see a list that sorts 273 before 41 before 7, because 2 < 4 < 7. (This is standard text processing for just about any programming language, and even an Excel worksheet. Most users immediately see something wrong with that ordering, because they assume that the values are numbers, but applications aren't as intuitive.)
- Integers only accept whole numbers. So 7 would be valid, but 3.1 would return an error. (3.1 is a decimal value, not an integer value.)
- Date/time properties specifically handle dates and times, which have very specific rules for performing any operations. For example, what does it mean to add "5" to a date/time value? 5 months? 5 days? 5 minutes?
Let's day you want the user to enter the date of an appointment. If the property is a text property, any of the following would be acceptable input:
- Friday
- July 21
- 4/17
- Martes
- 09/04/2019
Doing any kind of consistent processing on those potential inputs would be problematic. Setting the property type restricts the user to only entering acceptable, though not necessarily valid, data. So 09/04/2019 is an acceptable date, but it may not be valid if you want to ensure that the user is over the age of 18, or whether the date is in the future (an upcoming appointment) or in the past (a previous appointment).
Controls are UI elements that govern how a user interacts with the underlying property. So a calendar control presents the user with a calendar (or series of labeled fields) to select a date. The user doesn't need to worry about whether the application assumes MM/DD/YYYY format or DD/MM/YYYY format to represent a date. This ensures that what the user means when they enter 12/09/1983 matches what the application assumes the user meant - i.e., December 9 or September 12.
Edit Validate rules contain Java (or Javascript, I can't recall off the top of my head) fragments that are executed to process input and determine whether the value of a property matches a particular pattern. For example, Canadian postal codes are written in the format ANA NAN, where A is a letter and N is a single-digit number. Another good example is an email address - you can use an Edit Validate rule to ensure that the user entered the "@" symbol in the field, because without that value, the input is not a valid email address.
Edit Validate rules can validate data that's difficult to process any other way. You can configure a property to apply an Edit Validate rule to the data that the user inputs, and whenever the user provides a value in the field, the application tests to ensure that the entry is valid.
Validate rules use business logic to test the value of a field to ensure it satisfies business expectations. Some examples:
- A table of assets captures the value of a customer's financial accounts. A Validate rule can test that the user only enters positive (> 0) values for each asset and liability.
- A hotel reservation case requires that the user enter a check-in and check-out date. A Validate rule can test that the check-out date is greater (occurs after) the check-in date.
I'll stop here, in case there are any questions.
Just to add to the above, we should be mindful about using edit validate rules on properties as this would restrict it from being generic and reused across the application.
Having said that, it is also useful to use edit validate rules in cases where a property must adhere to certain formatting across the application. This will save us from having to write validate rules in every UI where the property is referenced and/or user entered.
Hope this helps, please let me know for any questions.