Documentation Archive Developer
Search
PATH  Documentation > WebObjects 4.5 > EOControl Reference

Table of Contents

EOValidation


(informal protocol)
Declared in:
EOControl/EOClassDescription.h


Protocol Description

The EOValidation informal protocol defines the way that enterprise objects validate their values. The validation methods check for illegal value types, values outside of established limits, illegal relationships, and so on. The Framework additions to NSObject provide default implementations of EOValidation, which are described in detail in this specification.

There are two kinds of validation methods. The first validates individual properties, and the second validates an entire object to see if it's ready for a specific operation (inserting, updating, and deleting). The two different types are discussed in more detail in the sections "Validating Individual Properties" and "Validating Before an Operation" .



Instance Methods


validateForDelete

- (NSException *)validateForDelete

Confirms that the receiver can be deleted in its current state, returning nil if it can or an NSException that the sender may raise if it can't. For example, an object can't be deleted if it has a relationship with a delete rule of EODeleteRuleDeny and that relationship has a destination object.

NSObject's implementation sends the receiver's EOClassDescription a message (which performs basic checking based on the presence or absence of values). Subclasses should invoke super's implementation before performing their own validation, and should combine any exception returned by super's implementation with their own:

- (NSException *)validateForDelete
{
    NSException *exception = [super validateForDelete];

    if ([balance intValue] != 0) {
        NSException *validationExample = [NSException
            validationExceptionWithFormat:@"The balance must be zero."];
      if (!exception)
         exception = validationException;
      else
         exception = [NSException aggregateExceptionWithExceptions:
            [NSArray arrayWithObjects:exception, validationException, nil]];
   }
   return exception;
}

See Also: - propagateDeleteWithEditingContext: (EOEnterpriseObject), + validationExceptionWithFormat: (NSException Additions)


validateForInsert

- (NSException *)validateForInsert

Confirms that the receiver can be inserted in its current state, returning nil if it can or an NSException that the sender may raise if it can't. NSObject's implementation simply invokes validateForSave.

The method validateForSave is the generic validation method for when an object is written to the external store. If an object performs validation that isn't specific to insertion, it should go in validateForSave.


validateForSave

- (NSException *)validateForSave

Confirms that the receiver can be saved in its current state, returning nil if it can or an NSException that the sender may raise if it can't. NSObject's implementation sends the receiver's EOClassDescription a validateObjectForSave: message, then iterates through all of the receiver's properties, invoking validateValue:forKey: for each one. If this results in more than one exception, the exception returned contains the additional ones in its userInfo dictionary under the AdditionalExceptionsKey. Subclasses should invoke super's implementation before performing their own validation, and should combine any exception returned by super's implementation with their own: 
- (NSException *)validateForSave
{
    NSException *exception = [super validateForDelete];

    if ([balance intValue] != 0) {
        NSException *validationExample = [NSException
            validationExceptionWithFormat:@"The balance must be zero."];
      if (!exception)
         exception = validationException;
      else
         exception = [NSException aggregateExceptionWithExceptions:
            [NSArray arrayWithObjects:exception, validationException, nil]];
   }
   return exception;
}

Enterprise objects can implement this method to check that certain relations between properties hold; for example, that the end date of a vacation period follows the begin date. To validate an individual property, you can simply implement a method for it as described under validateValue:forKey:.

See Also: + validationExceptionWithFormat: (NSException Additions), + aggregateExceptionWithExceptions: (NSException Additions)


validateForUpdate

- (NSException *)validateForUpdate

Confirms that the receiver can be inserted in its current state, EOreturning nil if it can or an NSException that the sender may raise if it can't NSObject's implementation simply invokes validateForSave.

The method validateForSave is the generic validation method for when an object is written to the external store. If an object performs validation that isn't specific to updating, it should go in validateForSave.


validateValue:forKey:

- (NSException *)validateValue:(id *)valuePointer forKey:(NSString *)key

Confirms that the value referenced by valuePointer is legal for the receiver's property named by key. Returns nil if it can confirm that the value is legal or an NSException that the sender may raise if it can't. The implementation can provide a coerced value by putting the new value into *valuePointer. This lets you convert strings to dates or numbers or maybe convert strings to an enumerated type value. NSObject's implementation sends a validateValue:forKey: message to the receiver's EOClassDescription. If that message doesn't return an exception, it checks for a method of the form validateKey: (for example, validateBudget: for a key of "budget") and invokes it, returning the result.

Enterprise objects can implement individual validateKey: methods to check limits, test for nonsense values, and otherwise confirm individual properties. To validate multiple properties based on relations among them, override the appropriate validateFor... method.

See Also: + validationExceptionWithFormat: (NSException Additions)



Table of Contents