Dirk, Craig,
>The design is quite simple: I've written a NSNotificationCenter clone with
>which you can register objects.
This is a good thing to keep around in any event. My +1 for adding
ObserverManager to Cayenne.
>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.
Current code has one flaw though - a shared instance of
TransactionEventManager contains state in "_objectsToBeNotified" so it
can't be reused by multiple threads simultaneously. But I guess we can fix
it easily.
>I guess we could model the validation machinery the same way so you only get
>validation if you need it.
Agreed.
> > 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.
True, I had to invent the ways around these limitations (exception stores
the key, but the message is derived later in the "catch" based on the key).
I guess my preferred implementation would be creating and throwing an
exception at the end of the validation to avoid chained try/catch. Instead
public validation API should pass around some kind of validation object
that is not an exception. Kind of like current Validator and ValidationInfo
in the project package.
Andrus
This archive was generated by hypermail 2.0.0 : Fri Jan 03 2003 - 02:04:15 EST