fishing for ideas..sorry if it's a bit incoherent, I'm ill with a fever.
Dirk Olmes wrote:
> The checking of updated and deleted objects sounds like a generally
> useful feature to me.
Me too! :)
> Is there a chance that we could make this a new feature of DataContext?
> I could imagine the following scenario:
>
> - User code call commitChanges on DataContext
> - DataContext iterates over all currently updated/inserted objects and
yup!
> sends them aboutToSave() (or whatever we'd like to name the method).
Let's think this through some more. I once mentioned that there should be
more 'delegates', ways to flexibly plug in custom framework logic instead
of subclassing. This might just be such a place. Same for some possible
future validation mechanism (two-step based: logical (value makes sense?)
and physical (width, range etc)).
I always liked EOF's delegate handling, despite its weaknesses (reference
handling, partially unclear semantics of delegate methods etc). Why not
steal the good parts?
- DataContextDelegate.will/didSaveChanges
- could be set per instance or globally: delegate class must be registered
with DataContext.setDefaultDelegateClass, or -instance - whatever works,
although I'm wary of single global instances because of class loaders,
possible synchronisation issues etc. unless they're necessary.
We talked about this in the 'Initial thoughts and suggestions' thread in
September; Andrus suggested that an event/listener system might be a good
alternative as well. This would make the delegates simple listeners to
DataContext events, similar to EOEvents. Will this be flexible and/or fast
enough? Laugh away, but I don't know enough about the general
implementation of the built-in listener concept in Java. Does it allow for
control of the event flow, the order of who gets what, when?
What consequences would this have for the order in which senders/listeners
are set up by the framework and the app?
> This method could be defined in an interface which the DataObjects would
> have to implement. Alternatively we could poke around with reflection (hmm).
My first idea as well: invoking optional 'class methods' (grr) implemented
in the DataObject as static methods might work, but is probably not such a
good idea since it cannot be formalized properly - interfaces cannot
contain statics, you can't properly subclass/override them etc. Nothing
but Java trouble :(
Much better to take a compositional approach.
> > Proposal: Modify createPermId to first check if the object has a
> > TempObjectId or not. If it's temporary, proceed. If not, assume it's
> > all ok and return immediately
>
> Sounds very sensible to me.
Yup.
-h
This archive was generated by hypermail 2.0.0 : Sat Nov 16 2002 - 09:41:51 EST