[bop-devel] inconsistencies / a need for a more formal B::OP specification?

Ivan Kohler ivan at 420.am
Thu Dec 7 02:26:49 PST 2006


On Thu, Dec 07, 2006 at 02:22:06AM -0800, Ivan Kohler wrote:
> On Thu, Dec 07, 2006 at 02:15:11AM -0800, Jo Rhett wrote:
> > Phil Lobbes wrote:
> > >This one is definitely trickier as the way you authenticate to various
> > >backends certainly varies but if we can find a standard-ish way to deal
> > >with most cases that would be nice.  For example:
> > >
> > >* PayflowPro requires auth info as part of %content
> > >* Paypal does not allow this
> > >* Authorize.Net needs login and transaction_key (at least for what I've
> > >  done it does -- password seems not used or perhaps completely optional
> > >  but it isn't the same as transaction_key)
> > 
> > I'd like to ACK this.  For various reasons it is really tough for our 
> > application to have %processor options.  It would be ideal for me if you 
> > could set all of the processor options later by method:
> > 
> > $tx->processor_opt(1);
> > $tx->processor_opt(2);
> > ...etc.
> > 
> > I'm not saying drop %processor_options, I'm saying that perhaps all 
> > module should support both ways of interacting?
> 
> Doesn't this already work?  B:OP's new method seems to call build_subs 
> for the %processor_options keys...

Never mind, I suppose you want the get/set subs to be built even when no 
%processor_options are passed... I guess gateway modules should have a 
way to declare their options (add a note to notes_for_modules_writers_v3 
on this new recommended practice), and the B:OP base class should take 
care of making sure the subs get built.

I think this means I need to stop procrastinating and get back to Real 
Work.  :)

-- 
_ivan


More information about the bop-devel mailing list