Comments for "ConstantContact"

» Submit Your Comment
Comments are only accepted during the "Proposal" phase. This proposal is currently in the "Finished" phase.
» Comments
Adam Harvey [2007-01-11 06:02 UTC] A few immediate thoughts for you: - RFC is probably the wrong category for the proposal; perhaps Mail or Web Services would be better. (I'd probably lean towards Web Services myself.) - Given the above, the class name would need to be changed to something like Mail_ConstantContact or Services_ConstantContact. - Instead of depending on libcurl, perhaps it might be better to look at using HTTP_Request, which doesn't require an external library. - It looks like the category, user name and password aren't run through urlencode before being submitted at the moment. - Before this gets to a vote, you'll need to review the PEAR coding standards for matters such as indenting -- the CS requires 4 spaces per indent level with no tab characters. Having said all the above, certainly don't let me discourage you from continuing, as this looks like it would be a useful addition to PEAR. Christian Weiske [2007-01-11 06:39 UTC] - Call the package Services_ConstantContact. Currently it looks as if it is a package called "Contact" of the "Constant" category. - The extension check has to be done when instantiating the class, not without any reason. Also using "exit" does not allow the programmer to handle this error in code. Throwing a PEAR_Exception would be best, or simply depend on it in package.xml - Don't use tabs but spaces (see PEAR Coding Standards in the manual, and the PHP_CodeSniffer package that checks your code automatically) - You don't urlencode username and password. - Please add parameter descriptions for methods like addMember - I don't know what "postCode" is.