<p>Wojciech, I know this proposal was just created, but please try to fill it out more quickly. Right now it is little more than a placeholder proposal.</p>

<p>Thanks.<br />
,Wil</p>

<p>Damn wiki just ate my reply! ><ac:emoticon ac:name="sad" /></p>

<p>Anyway. I hope I remembered all of what I had originally.<br />
Those are all suggestions and strictly IMHO. <ac:emoticon ac:name="smile" /></p>

<p>In short, I'd like a more object oriented approach, for example:</p>
<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
$message = new Zend_Services_Basecamp_Message();
$message->setTitle('hello')>setBody('lorem ipsum')>setCategory(1)>setProject(1)>send();

$message2 = new Zend_Services_Basecamp_Message();
$message->setTitle('another message');
$message->setCategory(2);
$message->setProject(1);
$message->send();
]]></ac:plain-text-body></ac:macro>

<p>It would be nice if your Zend_Services_Basecamp::__construct() would accept a Zend_Config instance in addition to the array.</p>

<p>Then, I would like to be able to recycle my object, let's say I have multiple basecamp accounts (different clients etc.):</p>

<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
$bc = new Zend_Services_Basecamp('http://example.org', 'till', 'pass1');
$messages = $bc->getMessages(1);

$bc->setUrl('http://example.net')->setPassword('pass2');
$messages = array_merge($messages, $bc->getMessages(1));
]]></ac:plain-text-body></ac:macro>

<p>Last but not least - 37Signals has a bunch of products, all come with a REST-API, I propose you change the name of this class to Zend_Services_37Signals_Basecamp.</p>

<p>Thanks for your feedback! <ac:emoticon ac:name="smile" /></p>

<p>I my opinion your object oriented approach looks good, but I thought about Zend_Service_Basecamp_*() classes as containers only to get data. All request methods are encapsulated in main Zend_Service_Basecamp class. I think most of the time people will get their data encapsulated in aray e.g. from Zend_Form, Zend_Db_Select, $_POST or $_GET arrays so i would like to vote for array aporach.</p>

<p>You can provide Zend_Config instance to Zend_Service_Basecamp::__construct() method by calling toArray() method:</p>
<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[$bs = new Zend_Service_Basecamp($config->toArray());]]></ac:plain-text-body></ac:macro>
<p>I would like to leave this decision over until <a href="http://framework.zend.com/wiki/display/ZFPROP/Zend_Config+Usage+in+Constructors+and+Factories+-+Bill+Karwin">Zend_Config Usage in Constructors and Factories</a> proposal will be reviewed. However, you can change your options using setOptions() method to reuse object later.</p>

<p>I've tought about naming this class in 37Signals hierarchy but I've not been sure if it conform our coding standards. I have checked it now and manual only says that "numbers are permitted in class names but are discouraged.". I think if the company name is 37Signals it would be reasonable to use name with numbers, but I would like to hear about it from a Zend Liaison.</p>

<ac:macro ac:name="note"><ac:parameter ac:name="title">Zend Official Response</ac:parameter><ac:rich-text-body>

<p>This is accepted to <strong>Zend Extras Incubator</strong></p>

<p>Suggested Changes:</p>
<ul>
<li>Move the constants into protected property so that the uris are not part of the<br />
exposed api, and this will make it easier to maintain a versioned api when/if basecamp comes to that.</li>
</ul>

</ac:rich-text-body></ac:macro>

<p>This proposal hasn't been updated in the past 6 months. Archiving it for now.</p>