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

[Jo Rhett]

Ivan Kohler wrote:
> On Thu, Dec 07, 2006 at 02:28:48AM -0800, Jo Rhett wrote:
>> Jo Rhett wrote:
>>> 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.
>> To clarify what I meant, our main purchase module has this code:
>> 
>> # Get the appropriate modules eval "use Business::OnlinePayment"; 
>> &processingError( $@ ) if $@; eval "use
>> Business::OnlinePayment::$CONFIG->{'Auth_Service'}"; 
>> &processingError( $@ ) if $@; my $transactor = new
>> Business::OnlinePayment($CONFIG->{'Auth_Service'});
> 
> Just for comparison, my app does something not unlike:
> 
> my $transactor = new Business::OnlinePayment(
> $CONFIG->{'Auth_Service'}, $CONFIG->{'Auth_Options'} );
> 
> and allows setting of the key/value pairs in the config UI.

Here's the difference.  My current code doesn't require an if/then/else
structure above it to setup Auth_Options correctly for all the different
gateways.

> Having a standard way for processor modules to declare their auth 
> options (and having a way to ask them what they are, maybe even for 
> descriptions) is looking like a better and better idea...  A 
> configuration UI could then use this for processor setup...

Hm. I'd have to think about that.  I'm still not seeing a way to avoid
an if/then/else before you even get started with B:OP.  My perfect world
is that the main code base has nearly zero if/then/else around B:OP modules.

-- 
Jo Rhett
Network/Software Engineer
Net Consonance