> > I was wonder what the thinking was behind removing the preSave method > > and if there are plans on implementing alternatives? The preSave method > > offered a nice way for the base class to provide a more managed and > > safer environment for a derived object to prepare itself to be saved. > > For example a method such as preSave could do the following: > > > > o Guarantee that the object has been modified, and really will be saved. > > o preSave would be called only once during a save operation. > > o The Base class could prepare itself for operations within the preSave > > that may change what is saved and offer protection against unexpected > > state changes. > > o The Base class could manage when the preSave is called in relation to > > other objects being saved and other preSave method calls. > > o Prevent infinite loops because of OM object method calls from within > > save operations. > > > > I lean toward making the save methods final, And only allowing the > > derived OM object to override preSave, or some such method. I think > > this allows more flexibility in future changes to torque without hosing > > current applications of it. > > > > Thoughts? > > I think all the things you mention above should be handled transparently. > The methods available to application objects should be as small as possible, > your basic CRUD and that's about it. I don't see much point in preSave(). >
I agree that these issues should be handled transparently, but I think that preSave is the way to do it. I also agree in simplicity. The preSave method allows the Base class OM an opportunity to handle these issues transparently. I know this is vague but I'll send some concrete examples. Thanks, Byron -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
