On Monday, September 1, 2003, at 03:33 AM, Dirk Olmes wrote:
>> 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. So
there is no clean way for them to interrupt the flow that caused the
event. And in general they should be unaware of the event dispatch
mechanism. 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.
Andrus
This archive was generated by hypermail 2.0.0 : Mon Sep 01 2003 - 17:15:30 EDT