Description: ------------ Added handler support to setPayment. The processor I'm building requires the expiry month and year as seperate fields, so I've added the handler code from _process to setPayment() in Common.php patch: --- /usr/share/pear/Payment/Process/Common.php 2004-04-13 15:45:48.000000000 +0800 +++ Common.php 2004-04-21 22:37:25.000000000 +0800 @@ -229,10 +229,25 @@ // Map over the payment specific fiels. Check out // $_typeFieldMap for more information. $paymentType = $payment->getType(); - foreach ($this->_typeFieldMap[$paymentType] as $key => $val) { - if(!isset($this->_data[$val])) { - $this->_data[$val] = $this->_payment->$key; + foreach ($this->_typeFieldMap[$paymentType] as $generic => $specific) { + $func = '_handle'.ucfirst($generic); + if (method_exists($this, $func)) { + //$this->debug("Calling {$func} to handle {$generic}"); + $result = $this->$func(); + if (PEAR::isError($result)) { + return $result; + } + } else { + // TODO This may screw things up - the problem is that + // CC information is no longer member variables, so we + // can't overwrite it. You could always handle this with + // a _handle funciton. I don't think it will cause problems, + // but it could. + if (!isset($this->_data[$specific])) { + $this->_data[$specific] = $this->_payment->$generic; + } } + } return true;

Could you please resend this patch? Patch complains that it's missing the unified diff header: ieure!Phaktory:~/Projects/Current/pear/Payment_Process$ patch -p4 < ~/1265.patch missing header for unified diff at line 4 of patch can't find file to patch at input line 4 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |--- /usr/share/pear/Payment/Process/Common.php 2004-04-13 |15:45:48.000000000 +0800 |+++ Common.php 2004-04-21 22:37:25.000000000 +0800 -------------------------- File to patch:

here's the patch again, if this doesnt work give us a yell and ill send it via email. --- Common.orig.php 2004-04-30 16:02:08.905151105 +0800 +++ Common.php 2004-04-21 22:37:25.000000000 +0800 @@ -229,10 +229,25 @@ // Map over the payment specific fiels. Check out // $_typeFieldMap for more information. $paymentType = $payment->getType(); - foreach ($this->_typeFieldMap[$paymentType] as $key => $val) { - if(!isset($this->_data[$val])) { - $this->_data[$val] = $this->_payment->$key; + foreach ($this->_typeFieldMap[$paymentType] as $generic => $specific) { + $func = '_handle'.ucfirst($generic); + if (method_exists($this, $func)) { + //$this->debug("Calling {$func} to handle {$generic}"); + $result = $this->$func(); + if (PEAR::isError($result)) { + return $result; + } + } else { + // TODO This may screw things up - the problem is that + // CC information is no longer member variables, so we + // can't overwrite it. You could always handle this with + // a _handle funciton. I don't think it will cause problems, + // but it could. + if (!isset($this->_data[$specific])) { + $this->_data[$specific] = $this->_payment->$generic; + } } + } return true;

It's still borking - could you email me the patch?

I've updated the patch for so it works with Payment Process 0.5.7 Its available at http://frood.cernun.net/stuff/Common.php-handle-support-typeFieldMap.patch I've also made changes to the patch so that in setPayment() the payment object is passed in by reference and linked to the current object by reference, no copying.

Can you clarify what (why) you are doing this in your patch: + if(isset($this->_payment->$generic)) + { + $this->_data[$specific] = $this->_payment->$generic; + } What's the order that things should happen with what I pasted above and what is just above that in your patch? -davidu

why i was doing? something to do with writing code at 3am :), ive updated the patch with the intended behaviour

Dear Maintainer, Your package payment_process has currently 3 open bugs. We urge you to take the necessary steps to solve the reported issues at your soonest convenience. If the bug issue hasn’t been addressed yet you are kindly asked to take the necessary steps to ensure a prompt resolution of the problem. If you already addressed the reported problem feel free to change the bug status as soon as possible. Regards David Costa PEAR Quality Assurance pear-qa@lists.php.net

This bug has been fixed in CVS. In case this was a documentation problem, the fix will show up at the end of next Sunday (CET) on pear.php.net. In case this was a pear.php.net website problem, the change will show up on the website in short time. Thank you for the report, and for helping us make PEAR better.