>>> Yeah, all this logic can exist as a part of
>>> DataContext.commitChanges(). Now, do we want to split
>>> "validateForSave"
>>> into separate "validateForInsert", "validateForDelete", etc., just
>>> like
>>> EOF does? I don't think it matters either way. I vote for a single
>>> method since object internally can determine its state. Maybe instead
>>> of "DataObject.validateForSave" call it
>>> "DataObject.validateForCommit"?
>>
>> I've been in situations where I had to perform certain validation
>> steps only
>> for newly created objects. So I'd vote for separate methods just like EOF
>> does, that shouldn't be hard to implement either.
>
>Doesn't matter to me.
>
>> The original idea was to use
>> DataContext events just for that, maybe that's still a good idea?
>>
>If I understand correctly this meant that event listeners (e.g.
>DataObjects themselves) would perform the validation. But event
>listeners logically are simply "consumers" of events, not delegates.
The DataObjects really should be performing validation. The original idea
was to register an object as event listener who triggers the appropriate
method(s) in the DataObjects in return, just like what's implemented in
ContextCommitObserver.
> So there is no clean way for them to interrupt the flow that caused the
>event.
Throwing an exception should "bubble through" all the way to
DataContext.commit in the current implementation, since that's single-threaded.
> And in general they should be unaware of the event dispatch
>mechanism.
Agreed.
>For instance, what if we'll make it multithreaded, and there
>will be no way to throw an exception from "validate" thread to stop
>commit, since "commit" is done in a different thread.
>Validation procedure on the other hand should interrupt the flow in
>case of errors and provide the user with detailed information about the
>failures.
Generally true. But we won't be able to use the multithreaded dispatch
mechanism for anything in cayenne that has influence on the flow of control. Any
validation methods, any updates to the object graph simply can't be
multithreaded. The only sensible use for multithreaded events I see is cross VM
notification.
-dirk
-- COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test -------------------------------------------------- 1. GMX TopMail - Platz 1 und Testsieger! 2. GMX ProMail - Platz 2 und Preis-Qualitätssieger! 3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post
This archive was generated by hypermail 2.0.0 : Tue Sep 02 2003 - 04:51:21 EDT