[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