Hi,
I put together a little validation class. It basically works in the same
way as NSValidation.DefaultImplementation:
validateValueForKey
validateTakeValueForKeyPath
The first method is the real workhorse. It will check for a
"validate'Key'" method and invoke it if it exits. Otherwise is will try
"validateValueForKey".
I posted to code on the webobjects mailing list. It just a quick hack I
did last night, so don't expect much.
In any case, I'm having second thought about this entire "validation"
thing... First of, I never really used it in EOF. Except, some time, the
generic method for checking dumb things like string length or such.
Which doesn't really belong to an EO though. In any case, why bother
with an external validation mechanism? Why not simply use old fashioned
setter methods? If the setter does not like a given value, simply
correct the problem and/or throw an Exception there. No real need for
externalizing validation. Plus, separating validation from setting the
value introduce a potential dichtonomy: it does rely on the "good will"
of a third party to do the right thing (eg call validate and then set).
I think that all this validation business should be privy to the setter
methods.
What do you think?
PA.
This archive was generated by hypermail 2.0.0 : Tue Sep 03 2002 - 04:33:58 EDT