[bop-devel] AuthorizeNet MD5 Check

Ivan Kohler ivan at sisd.com
Tue Sep 25 16:32:56 PDT 2007


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.

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

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

Again, that's very much the whole point of having a family of related 
modules that (try to) offer a common interface.

Tangent: Jo - yes, there should be no eval required for ->process 
either, but you never followed through with making that happen.  :)

> I'd suggest separate gateway, request, and response objects, too.  But
> that's another topic.

Suggestions are cheap.  Show us the code.  :)

Don't forget that you need to implement a backwards-compatibilty layer 
for both end-users and module authors, and write migration documentation 
for both audiences.

-- 
_ivan


More information about the bop-devel mailing list