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

[Ivan Kohler]

On Thu, Dec 07, 2006 at 09:28:22AM -0800, Jo Rhett wrote:
> 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.

I don't think I follow.  I don't have or require an "if/then/else 
structure to setup Auth_Options".  I just have an option in the UI to 
set name-value pairs.

  If we went forwared with the plan to have modules 
declare their auth options, I could ask the modules for the same infouse 
the same info used to 
instantiate your getter/setters subs to pre-populate the keys.

> >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.

My own usage certainly does not have this "if/then/else" structure you 
keep going on about.  You keep using that word.  I do not think it means 
what you think it means.  :)

Seriously, like I've been dancing around in my previous message, here's 
a general idea for you to get the getter and setter subroutines you're 
looking for. I'm certainly not opposed to the getter/setter for auth 
options idea one bit and am not arguing against it, even if I haven't 
the foggiest idea what getter and setter subroutines get you that a 
config hash doesn't (I don't think you're correct in saying one style 
requires if/then/else processor-specific logic and the other doesn't).

(If you're looking for other normalization, bring up the specifics of 
what you'd like to normalize, don't just go on about how awful your 
current "if/then/else" hacks are, eh?)

So:

- Processor modules must declare the authentication (and other 
  initialization options) they support, and optionally some 
  documentation on those.  Say, they should have an "auth_options" sub 
  which returns a hash reference of options and descriptions.

- Add information to notes_for_module_writers_v3 about the new 
  "auth_options" subroutine that should be declared, and concerning the 
  deprecation of login/password in transaction content (should 
  continue to work but carp, if it did previously).

- B:OP asks the processor module for the auth options it supports and 
  call "build_subs" on those options to create your getters and setters.

- B:OP should also provide a way to retreive auth_options info for a 
  processor module (as a class method?  seems unnecessary/wrong to 
  instantiate a B:OP transaction object).

What do you think?

-- 
_ivan