>>This was at least one of the problems that was thrown up with my recent
>>changes (I created an exhibit without a gallery). Maybe it's time we had
>>client-side validation against the DataMap at commit time... configurable
>>on or off in case the end-developer wishes to just use the DB level error
>>checking, no matter how obtuse the java.sql.Exception messages may be.
>>My next project perhaps?
>
> This maybe a cool add-on. IIRC we discussed it in September on this list.
Yes and I promised to put together something. While the original concept has
been ready for quite some time I've always wanted to make the solution
better and better. Guess I couldn't come to an end.
I've put together what I have so far. Get it from
http://xanthippe.dyndns.org/external/CayenneDataObjectNotifications.zip
It's an eclipse project, just import it into your workspace. The project
assumes the existence of a project named "cayenne" in the same workspace; this
should be the case when you check out cayenne from CVS.
The design is quite simple: I've written a NSNotificationCenter clone with
which you can register objects.
The class TransactionEventManager registers an instance to receive
Notifications posted from DataContext before and after a commitChanges takes place.
When the DataContext commits, the registered instance will receive a
Notification, it then iterates over the list of new, updated and deleted objects and
checks whether the objects implement the TransactionEvents interface. If they
do, they will be sent willCommit()/didCommit().
This solution turns out ot be as unintrusive to the framework as possible:
The only modifications one has to make to DataContext is the posting of events
upon certain control points. If you want the transaction event machinery,
simply put TransactionEventManager.registerForDataContextEvents(); somewhere in
the beginning of your app.
I guess we could model the validation machinery the same way so you only get
validation if you need it.
SIDENOTE: The project includes an (most probably outdated) copy of
DataContext, I wanted to be the project as self-contained as possible. In order to
make it run with the latest version of cayenne, just have a look at my additions
to the commitChanges method and transfer them to the actual DataContext
implementation.
> Ironically after that I tried using EOValidation in WebObjects as a
> customizable validation mechanism for the first time in my long WO
> experience. Despite some ugliness catching and rethrowing validation
> exceptions, this works and is an o.k. way to handle validation.
While WO validation is nice, it lacks in some places: did you ever try to
localize the validation messages? You'll end up parsing the validation message
since the messages are hard-coded <stinky, stinky>. Also, all the different
constraints (not null, required relationship, string length etc.) throw
NSValidation.ValidationException. I'd much rather have different kinds of exeptions
for finer grained validation exception handling.
-dirk
-- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
This archive was generated by hypermail 2.0.0 : Thu Jan 02 2003 - 04:10:39 EST