[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