>WOComponent has a new method in WO4,
>-validationFailedWithException:value:keyPath:
>
>It gets called during the takeValues phase. Looks like it gets called
>once for each property that fails validation. I'm wondering how this
>was intended to be used? I can imagine having it set some variables
>that would control the behavior of an action method (e.g. set some
>"validation failed" messages and maybe redisplay the page vs. calling
>tryToSaveChanges and returning to another page), but I'm wondering
>whether there's a more elegant usage that I'm just not thinking of...?
It's a simple post-formatter-failure 'callback' that can be used
exactly in the way you suggest: to catch (or ignore) a formatting failure after form submission. One should note that one rather unhelpful side effect of not implementing this method is the fact that failed formatter operations which directly operate on EO attributes will revert to their previous value, i.e. if you have, say, some date and entered a nonsense string, the previous, valid date will be stuck back into the EO. This can lead to the situation that - if you don't implement/catch -validationFailedWithException:value:keyPath: - a user enters data and the edit is quietly lost. Nicely defensive behaviour, but not particularly well documented.. Luckily, there's an easy (ha!) remedy: if you want to insist on havingthe formatter stick the incorrect value (read: nil) into your presented
EO because your business logic is responsible for EO validation, implement -validationFailedWithException:value:keyPath: to just do a [self takeValueForKey: theKeyPath]. This will make the component hit itself on the head with the given key path to the bound attribute, and your EO validation logic can do its work afterwards as usual. This helps keep the validation logic where it belongs (the EO) and reduces the code you have to write in WO (which cannot be reused anywhere else). >How did people deal with EO validation results (in WO) prior to WO4? By writing a full-blown validation & exception extension/replacement, simply because the stock mechanisms are IMHO not really useful for rapidly evolving, maybe localized, complicated data entry apps with lots of fields on every forms page. :-/ This is one area in EOF and WO that could need real improvement. Regards, Holger PS: if anybody from the WO or EOF teams is interested in how theseimprovements might look, I honestly beg you to drop me a line.
The necessary additions are conceptually simple and nonintrusive, but would save many customers a lot of unnecessary code and time.
