In a
previous posting I provided some jscript that can be used to validate phone number formats. In order to invoke the validation for a phone number field I mentioned that you need to create an "on change" event that would pass in the attribute name and attribute description i.e.:
function Attribute_OnChange() {
PhoneNumberValidation("attributeName", "attributeDescription");
}
I thought this would provide a good example for demonstrating the ability to use the execution context because you can obtain the field name and label (by extension) via the execution context which on the surface is a good thing since you avoid hard-coding as in the example above (and you can apply this to all phone number fields in the system). And therefore in theory you could simplify that example as follows:
function PhoneNumberValidation(context) {
var phone = context.getEventSource().getName();
var phoneDesc = Xrm.Page.getControl(context.getEventSource().getName()).getLabel();
var ret = true;
var phone1 = Xrm.Page.getAttribute(phone).getValue();
var phone2 = phone1;
if (phone1 == null)
return true;
// First trim the phone number
var stripPhone = phone1.replace(/[^0-9]/g, '');
if ( stripPhone.length < 10 ) {
alert("The " + phoneDesc + " you entered must be at 10 digits. Please correct the entry.");
Xrm.Page.ui.controls.get(phone).setFocus();
ret = false;
} else {
if (stripPhone.length == 10) {
phone2 = "(" + stripPhone.substring(0,3) + ") " + stripPhone.substring(3,6) + "-" + stripPhone.substring(6,10);
} else {
phone2 = stripPhone;
}
}
Xrm.Page.getAttribute(phone).setValue(phone2);
return ret;
}
The only difference is that instead of the "phone" and "phoneDesc" parameters being passed into the validation function, the execution context is instead passed in and the phone attribute and its corresponding phoneDesc label are obtained via the context as local variables. The rest stays the same.
In order for this to work, you would update the "on change" event to call the PhoneNumberValidation function directly and check off the "pass execution context as first parameter" as shown:
So that's the theory and I think it demonstrates quite nicely how the execution context can be used.
Having said that, in this particular example, I prefer using the explicit technique referenced in the
original posting. The reason for this is because the on change event in this validation example (and probably relevant for most data validation cases) has a dual function -
The first is to provide the necessary validation as part of the field on change event as the example above will accomplish quite well.
The second is to be called from the on save event to make sure that even if users ignore the message from the on change event they will not be able to save the form via the validation from the on save event (the PhoneNumberValidation function returns a true or false value to indicate whether validation was passed or not). And when the function is called from the on change event the specific field context is not going to be there anyway making it necessary to put in some additional logic in order to handle correctly. Therefore what you gain from using the execution context in this example is likely to be offset by requirements for special handling required by the on save event.
