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
[EMAIL PROTECTED]
There are 10 types of people in the world, those who count in binary,
and those who don't.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
