[bop-devel] AuthorizeNet MD5 Check

[Bill Moseley]

On Tue, Sep 25, 2007 at 04:32:56PM -0700, Ivan Kohler wrote:
> On Tue, Sep 25, 2007 at 03:00:30PM -0700, Bill Moseley wrote:
> > On Tue, Sep 25, 2007 at 02:03:07PM -0700, Ivan Kohler wrote:
> > 
> > 
> > > Yes, the advantage is very much the whole reason why we have a class of 
> > > modules within a framework and not disparate modules.
> > > 
> > >    my $tx = Business::OnlinePayment->new( $processor, %options );
> > > 
> > > is better than:
> > > 
> > >   my $tx = eval "Business::OnlinePayment::$processor->new( \%options )";
> > >   die $@ if $@;
> > 
> > You don't mean string eval there.  And I don't think you mean eval
> > block, either.
> 

I thought we were talking about how the end-user calls B::OP.

The current way is:

    $tx = Business::OnlinePayment->new("AuthorizeNet");

Where I was suggesting that end-users pick their payment gateway of
choice and do:

    $tx = Business::OnlinePayment::AuthorizeNet->new;

Which means you could do:

    $tx = Business::OnlinePayment::MyAuthorizeNet->new;

which sub-classes AuthroizeNet.  But, I understand that's not suppose
to be supported.


> Yes, I sure did.  $processor needs to be interpolated.

Maybe we are talking about different things.  What's the eval string for?

    my $package = "Business::OnlinePayment::$processor";
    $package->require || die "Failed to load package '$package': $@"
    my $tx = $package->new;



> Which is why we offer the first interface instead.  "AuthorizeNet" 
> should not be hardcoded.

That was my question.  Do people use different processors at the same
time?

I'd probably do, as above:

    my $processor = $config->payment_processor;
    my $gateway = $processor->new ( \%options );

> Suggestions are cheap.  Show us the code.  :)

Or sure.  Suggestions AND implementation?  That's the hard part. ;)



-- 
Bill Moseley
moseley at hank.org