> Yeah, that's a pretty common situation when you have to populate some
> DataObject properties with external data (i.e. data not available within
> DataObject itself) in certain points of the object lifecycle. I think
> having a subclass of DataContext is entirely reasonable.
The only concern I have about the subclassing is the EventSubject static
variables:
// DataContext events
public static final EventSubject WILL_COMMIT = EventSubject.getSubject(
DataContext.class,
"DataContextWillCommit");
public static final EventSubject DID_COMMIT = EventSubject.getSubject(
DataContext.class,
"DataContextDidCommit");
public static final EventSubject DID_ROLLBACK = EventSubject.getSubject(
DataContext.class,
"DataContextDidRollback");
They use the DataContext class, so I was wondering if thats going to
adversely affect anything if I am using my DataContext subclass everywhere?
If thats a non-issue, then I'll gladly switch to a subclass.
> Re: "WILL_COMMIT". I guess in the meantime we need to fix that and fire it
> prior to validation (could someone please open an issue in Jira?) On the
> long run we need to think of a big picture for DataObject lifecycle and
Actually, I think firing after validation makes perfect sense. I can imagine
times when I want to know that a commit is going to happen before I do
something special. If validation hasnt occurred yet, then there is a chance
that we won't actually proceed with the commit. I think that it would be
better to have another event that was generated before validation, e.g.
"STARTING_COMMIT_PROCESS" (or something better :-). However, it may be
better to delay that until the "big picture" becomes clearer :-)
Thanks
Derek
This archive was generated by hypermail 2.0.0 : Mon Dec 06 2004 - 17:38:04 EST