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.