EOValidation

(informal interface)
Implemented by:
EOEnterpriseObject
EOCustomObject
EOGenericRecord

Package: com.webobjects.eocontrol

Interface Description

The EOValidation interface 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. EOCustomObject and EOGenericRecord 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" (page 415) and "Validating Before an Operation" (page 416).

Instance Methods

validateForDelete

public abstract void validateForDelete()

Confirms that the receiver can be deleted in its current state, throwing an NSValidation.ValidationException if it can't. For example, an object can't be deleted if it has a relationship with a delete rule of EOClassDescription.DeleteRuleDeny and that relationship has a destination object.

EOCustomObject'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 thrown by super's implementation with their own.:

See Also: propagateDeleteWithEditingContext (EOEnterpriseObject),

validateForInsert

public abstract void validateForInsert()

Confirms that the receiver can be inserted in its current state, throwing an NSValidation.ValidationException if it can't. EOCustomObject'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

public abstract void validateForSave()

Confirms that the receiver can be saved in its current state, throwing an NSValidation.ValidationException if it can't. EOCustomObject's implementation sends the receiver's EOClassDescription a validateObjectForSave message, then iterates through all of the receiver's properties. If this results in more than one exception, the exception returned contains the additional ones in its userInfo dictionary under the NSValidation.ValidationException.AdditionalExceptionsKey. Subclasses should invoke super's implementation before performing their own validation, and should combine any exception thrown by super's implementation with their own.

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.

See Also: NSValidation.ValidationException constructor

validateForUpdate

public abstract void validateForUpdate()

Confirms that the receiver can be inserted in its current state, NSValidation.ValidationException. EOCustomObject'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.