| Anjo,
That's great that you went in and fixed EOF, but my point is that EOF should do all this "out-of-the-box." And apparently you agree with me, since you fixed these issues in Project Wonder. I don't get why you guys don't just go off and build you own web framework and be done with it.
I guess I'll just keep my big mouth shut and let you guys have WebObjects and Project Wonder. I'm about done with it anyway. I'm starting to see the light that Apple has no interest in supporting developers with their own solutions, so now we're stuck with trying to get support from an open source community that has more interest in criticizing people than trying to help.
In any case, why would I want to continue to use a development framework that requires major portions of the core classes to be patched in order to work in a way that makes sense. I suppose that's the only way to get things done, since you don't have access to the actual core classes from Apple, and Apple obviously has no interest in fixing the system themselves. The less Apple is interested in this framework, the less I'm becoming interested in it.
If your point here is, "Use our stuff or go find something else." We'll I guess it's time to go find something else.
On Dec 2, 2006, at 2:43 PM, Anjo Krank wrote:
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
-- Robert Walker
There are 10 types of people in the world, those who count in binary, and those who don't.
|