| Hi, Michael, On Feb 20, 2006, at 5:41 PM, Michael DeMan wrote: Does anybody know if: It works in the opposite direction for EOCustomObjects' default implementation. From the API for 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.
If you insert your EO into an EOEditingContext as it's created, then "...do some transaction oriented stuff", validate your object fields, execute a transaction on your 3rd party system and then do an editingContext.insertObject() followed by an editingContext.saveChanges(), there should be no problem.
The validateForSave method is appropriate here for generic validation (i.e. validation not specific to insert, delete or update). The validateForSave method of EOCustomObject, according to the API, does the following: 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 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. Specifically, when it says "... then iterates through all of the receiver's properties." it means that for each class attribute xxx of your EO, it sends a validateValueForKey("xxx") message to your EO which, by default, looks for a method in your class of the form, validateXxx() and executes it.
As Chuck suggested: The easiest way to see is to add this to validateForIinsert: NSLog.out.appendln(new RuntimeException("backtrace")); and then look at the backtrace. Regards, Jerry -- __ Jerry W. Walker, WebObjects Developer/Instructor for High Performance Industrial Strength Internet Enabled Systems jerrywwalker@gee-em-aye-eye-ell.com 203 278-4085 office |
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
