new methods in torque related to save()

[John McNally <jm...@collab.net>]

I just added a couple protected methods to the OM's to allow for some
preprocessing prior to saving the object.  The simple one is a doPreSave
method which has an empty default implementation, but provides a hook to
allow pre-processing by the om.  The second one involves more classes
and needs to be turned on with the secureSaveMethod property.  It
modifies the save methods so that they take an
object implementing the SecurityInfo interface.  It also adds a
protected method securityCheck that calls the hasPermission method on
SecurityInfo.  If the test fails a SecurityException is thrown and
doPreSave and the rest of the save operations will not occur.  Since
Persistent had just had the save methods added, I extended the interface
and moved the save definitions to the children.  Any comments or
suggestions for improvement?

john mcnally

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

Re: new methods in torque related to save()

[Daniel Rall <dl...@finemaltcoding.com>]

John McNally <jm...@collab.net> writes:

> I just added a couple protected methods to the OM's to allow for some
> preprocessing prior to saving the object.  The simple one is a doPreSave
> method which has an empty default implementation, but provides a hook to
> allow pre-processing by the om.  The second one involves more classes
> and needs to be turned on with the secureSaveMethod property.  It
> modifies the save methods so that they take an
> object implementing the SecurityInfo interface.  It also adds a
> protected method securityCheck that calls the hasPermission method on
> SecurityInfo.  If the test fails a SecurityException is thrown and
> doPreSave and the rest of the save operations will not occur.  Since
> Persistent had just had the save methods added, I extended the interface
> and moved the save definitions to the children.  Any comments or
> suggestions for improvement?

What's the value of this over just overriding save() and calling
super.save() as your last op?

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

Re: new methods in torque related to save()

[Jon Stevens <jo...@latchkey.com>]

on 9/10/01 1:16 PM, "John McNally" <jm...@collab.net> wrote:

> I just added a couple protected methods to the OM's to allow for some
> preprocessing prior to saving the object.  The simple one is a doPreSave
> method which has an empty default implementation, but provides a hook to
> allow pre-processing by the om.  The second one involves more classes
> and needs to be turned on with the secureSaveMethod property.  It
> modifies the save methods so that they take an
> object implementing the SecurityInfo interface.  It also adds a
> protected method securityCheck that calls the hasPermission method on
> SecurityInfo.  If the test fails a SecurityException is thrown and
> doPreSave and the rest of the save operations will not occur.  Since
> Persistent had just had the save methods added, I extended the interface
> and moved the save definitions to the children.  Any comments or
> suggestions for improvement?
> 
> john mcnally

It looks very good and will make life in the OM's easier in Scarab for sure.

I kind of cringe with the method name "doPreSave()", but I don't have a
better suggestion for a name.

One idea for the future might be to employ a valve/pipeline model on top of
the processing so that people could add valves within the chain of execution
wherever the pipeline dictated. However, this would probably require about a
bazillion times more work and I'm not sure it would be really worth the
effort. In other words, people might also want a doPreDelete(),
doPreSelect(), doPreSetAttributeId() etc...the valve/pipeline model would
allow for that without needing to constantly add doPre* methods all over the
kingdom.

John: On a side note, I just figured out last night that Intake has a
dependency on Torque (the import org.apache.torque.om.Retrievable
interface). It might be nice to get rid of that if possible (maybe copy the
interface into Intake Service) as well as add some documentation to the site
that says that objects which may have $intake.mapTo() called on them need to
implement that interface. It had me stumped last night at 1:00am because I
created an object which wraps around two OM objects (ie: the result of a
join) and I'm using that within Intake's model to populate form fields.

thanks,

-jon


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org