Adding Validation
Another common requirement of business logic is that it validates all data that users enter, both to ensure that the data will work with other business rules and also to ensure the integrity of stored data. Enterprise Objects provides many different hooks to validate data. When you provide certain validation methods in your business logic classes, Enterprise Objects automatically invokes them to validate your data.
The EOValidation interface in the control layer defines these validation methods:
validateClientUpdatevalidateForDeletevalidateForInsertvalidateForSavevalidateForUpdate
In this section:
Validating Before Certain Operations
Validating Individual Properties
Validating Before Certain Operations
Some of these methods are invoked during certain Enterprise Objects operations, and by overriding them in your business logic classes, you can implement custom validation rules. When an application performs one of these operations on an editing context (save, delete, insert, or update objects), the editing context in which the operation is invoked sends a validation message to its enterprise objects. Based on the result returned from those enterprise objects, the operation is either allowed to continue or is refused.
For example, if you implement validateForSave in a particular enterprise object class, when a user attempts to save changes to a particular enterprise object (thereby invoking saveChanges on the object’s editing context), that object’s editing context first asks the enterprise object if it’s in a consistent state to save. It does this by invoking validateForSave. If validateForSave doesn’t throw an NSValidation.ValidationException, the operation is allowed to continue. However, if validateForSave throws an NSValidation.ValidationException, the save operation is not allowed to continue.
It’s up to you to decide what constitutes a valid enterprise object. In this example, you could write custom business logic in validateForSave that makes sure the enterprise object’s data is valid based on your application’s business rules.
All classes that implement the EOEnterpriseObject interface include a default implementation of the validateForOperation methods. The default implementation of validateForDelete, for example, validates that an enterprise object’s relationships conform to their specified referential integrity rules.
Important: Because all enterprise object classes inherit default implementations of the validateForOperation methods, you must invoke super’s implementation before performing custom validation logic.
The default implementations of validateForSave, validateForInsert, and validateForUpdate invoke validateValueForKey for each of an object’s class properties. See “Validating Individual Properties” for more information on validateValueForKey.
Validating Individual Properties
In addition to the validation that occurs before certain operations are allowed to proceed, you can also validate the individual properties of an enterprise object. The EOValidation interface defines another validation method, validateValueForKey. The default implementation of validateValueForKey searches for and invokes methods of the form validateKey in enterprise object classes. You implement a validateKey method for each property of an enterprise object you want to validate.
For example, it’s common to want to validate a zip code field to make sure that a user entered five numbers (for zip codes in the United States). In an enterprise object class in which the zipcode field exists, you add this method:
public Object validateZipcode(Object zipcode) throws NSValidation.ValidationException { |
if ((Number)zipcode.length() > 5) { |
throw new NSValidation.ValidationException("Invalid zipcode."); |
} |
else return zipcode; |
} |
When a user tries to assign a value to the zipcode property of an enterprise object, the default implementation of validateValueForKey invokes validateZipcode. Based on the result of that method, the user-entered value is either allowed to be assigned to the property or refused. Immediately before invoking validateKey methods, the default implementation of validateValueForKey validates the property against constraints specified in the data model, such as null constraints and referential integrity rules.
Another common use of validateValueForKey is to coerce user-entered data and return the coerced value. For example, users may enter a phone number in a text field in a form. That text field is bound to the phoneNumber attribute of an enterprise object. Rather than force users to enter the phone number in a particular format, such as with dash or period separators, you can let them enter a number in any format. Then, in the validatePhoneNumber method, you can coerce that number into the format you want and return the coerced string rather than the user-entered string.
Last updated: 2007-07-11
  |
||
|
|
|
|
| ||
Get information on Apple products.
Visit the Apple Store online or at retail locations. 1-800-MY-APPLE Copyright © 2007 Apple Inc. All rights reserved. | Terms of use | Privacy Notice |