Hello,
I have a property of an enterprise object bound directly to a
WOTextField. When the user enters a value into the text field, the
WOAssociation sets the value on the EO immediately after the form is
submitted. This has the unwanted side effect which results in
validateTakeValue:forKeyPath: getting called immediately thereafter. If
the user enter's an invalid value (i.e. a value that is too long to fit
the width of the property), then the validate method raises an
exception, as seen in the following backtrace:
#0 0x320411e0 in -[NSException raise] ()
#1 0x44022624 in -[NSObject(EOClassDescriptionPrimitives)
validateTakeValue:forKeyPath:] ()
#2 0x4203d3ba in -[WOKeyValueAssociation setValue:inComponent:] ()
#3 0x4202ca68 in -[WOTextField takeValuesFromRequest:inContext:] ()
#4 0x4202365a in -[WOHTMLDynamicElement(WORequestHandling)
takeValuesFromRequest:inContext:] ()
#5 0x420202ba in -[WOForm(WORequestHandling)
takeValuesFromRequest:inContext:]
The exception is being caught somewhere (probably by the
WOKeyValueAssociation). This has the end result that 1) The value does
NOT get set on the EO, and 2) The exception does NOT get propagated to
the editing context when 'tryToSaveChanges' is called.
This behvaior appears to be markedly different from the behavior in
WO3.1. In that version, the end result would have been that the
validation exception would have been raised (and caught) during
tryToSaveChanges, thus allowing for intervention (like throwing up an
alert page).
Has anyone else noticed this?
Eric
