Open zot24 opened 10 years ago
I do like this yes, as we add more methods, versions and endpoints are becoming messy!
How about Lib/PaypalClassic.php
and Lib/PaypalREST.php
and then the main plugin Lib/Paypal.php
simply abstracts all the methods?
As long as the main plugin methods are uniform and don't include any messy configuration, this could be a good move!
I'll start a new branch and separate the test cases accordingly for now, then we can see how best to split the logic.
Cool mate!
I'm just creating more and more methods for the REST API like payment
with and without creditcard, get stored credit card
and more.
I'll push it on my fork and then I'll merge with your new approach and do a pull request against you again :)
Hi Rob!
Sorry for the delay.
What do you think about splitting the logic like this (is kind of what you said here)?
Yes that looks like a step in the right direction! How do you think we can approach testing though? I noticed many new private methods which had no public interface nor were being called from the main public methods - so testing these is going to be impossible.
Do you think there is also a way of reducing the number of files needed? What was the intention behind including a Controller/Component?
I was looking made easy use the library on our CakePHP projects something like by adding another layer over the Lib
files:
// That way the library to use will be autoinitialize in the component
// and we'll be using an interface to do all the call agaist either the classic api or the rest api
public $components = array('Paypal => array(config => array('api' => 'rest')));
$this->Paypal->doPaypalPayment($object):
$this->Paypal->doCreditCardPayment($object):
About testing the private method we can do it by using a proxy class or something like that.
What do you reckon about splitting up the code between the Classic API logic and the new Restful API logic to keep our more code clean and modular?