Re: Single table inheritance and non-null attributes
Re: Single table inheritance and non-null attributes
- Subject: Re: Single table inheritance and non-null attributes
- From: Anjo Krank <email@hidden>
- Date: Sat, 2 Dec 2006 20:43:13 +0100
Am 01.12.2006 um 21:27 schrieb Robert Walker:
I actually made change a while back that is, indirectly, related to
this issue. A simply stopped using any of the validations in the
EOModel, and I now do all my validation in the custom classes.
This may sound strange, but there is a method to my madness. I
want to have control over the validation messages that will be
displayed to the user. Especially when it comes to failures on
relationship constraints. Instead of the technobabble that EOModel
products, I want something more human readable like "Please assign
the user to a department before saving." Or changing the default
string for "not null" to something like "Date cannot be left
empty. [Example: 12/01/2006]"
Yaddayadda. Project Wonder. Yadda.
Yawn.
To elaborate some more: we have custom validation parsers since
basically Day One (cudos to Max for that). We even allow for multi-
property failures like "you need a Foo if you have a Bar but no Baz".
All of this - of course - with localization support and model-based,
so you don't need custom components. You can also provide your own
messages on a fall-back fashion (NOT NULL on Foo.bar: Dude, you suck!
No bar here!, NOT NULL on everything else: Excuse me, will you please
provide a foo?).
So there.
EOF will throw exceptions in the following order:
1. Formatters on input fields such as date/time and number
formatters. (Oh, and try and find an easy override for the goop
this spits out)
2. Validation rules in EOModeler.
3. Property level validators.
4. Operational validators (insert, update, save, delete)
This means that if validation fails in the model your properly
level and operational level validators are never called. This is
one of my biggest complaints about EOF. I would much prefer that
number 2 (above) was moved to the end of the list so that custom
classes get first chance to validate rather than the model.
You can easily create your own class description which does this
validation before everything else (which is what we do).
That would make a lot more sense in my opinion.
Depends on use case...
Cheers, Anjo
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden