Re: New hierarchy for payment processors?

David Croft wrote: > > On Mon, 24 Jul 2000, Stig Sfther Bakken wrote: > > > PEAR is intended for exactly this kind of thing. It's ok to have it in > > the main CVS right now, but I think we should move most of the classes > > out to separate distributions when the tools are done. > > Hi Stig, thank you. You'll probably have noticed I've committed > Payment/Verisign.php to the CVS tree now. I've put a big "DO NOT USE" > across the top as I'd like to solicit any input from you guys and from my > co-developer on the pfpro extension before I go any further. > > I like the idea of being able to package up the extension's C files and > the related php files together and distribute them as a single package. > Presumably this relies on dynamic loading in PHP which I have yet to play > with. > > I also like the concept of returning Exception objects, but I just know > people won't bother to check them on every method call. Do you think the > Zend guys would go for a Java-like throw/try..catch exception mechanism? I've discussed this briefly with Zeev. As usual, the reply is "hell breaks loose": he's not convinced yet. :-) > I was wondering about the @param and @return comments in some of the pear > files. Is there some kind of tool already written to parse these? They > look about like javadoc I think, but I have no experience with that. They are Javadoc. Ulf is making a tool for extracting these to generate HTML or other formats, I've seen an early version of it and it looks great. > Finally... the Payment/Verisign class is useless without the pfpro > extension installed. I've put a check for this in the actual process() > method, but I was wondering whether it would also be good form to do > something like this, outside of the class definition so it checks when the > file is loaded: > > if (!extension_loaded('pfpro')) { > die('Payflow Pro module is not compiled into PHP. Compile PHP using > --with-pfpro.'); > } You should probably do this on the top-level of Verisign.php. I think the reasonable default behaviour for PEAR packages would be to try loading the extension if it is not present, and if the load fails, die (as the first exception to the "never die by default" rule :-): if (!extension_loaded('pfpro')) { // XXX we need to abstract away the ".so" here because // some OS'es use other suffixes (.dll on Windows, possibly .sl on HP-UX?) if (!dl('pfpro.so')) { die('Payment/Verisign.php: requires the "pfpro" PHP extension to be installed'); } } - Stig