Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Zend Framework: Zend_Service_37Signals_Basecamp Component Proposal

Proposed Component Name Zend_Service_37Signals_Basecamp
Developer Notes http://framework.zend.com/wiki/display/ZFDEV/Zend_Service_37Signals_Basecamp
Proposers w.naruniec@gmail.com
Zend Liaison Ralph Schindler
Revision 0.1 - 13 March 2008: Placeholder
0.2 - 30 May 2008: Initial version
0.3 - 13 July 2008: Ready for Review
0.4 - 29 July 2008: Ready for Recommendation
0.5 - 21 May 2009: Sync with new REST API (wiki revision: 23)

Table of Contents

1. Overview

Zend_Service_37Signals_Basecamp is an implementation of the Basecamp REST API. All methods return an instance of Zend_Rest_Client_Result.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • This component will implement all API functions.
  • This component will handle authentication.
  • This component will accept array or Zend_Config object as configuration options
  • This component will not handle YAML requests.

4. Dependencies on Other Framework Components

  • Zend_Rest_Client
  • Zend_Service_Exception

5. Theory of Operation

Components makes request, parse response and return data.

6. Milestones / Tasks

  • Milestone 1: [DONE] Publish proposal and prepare class sekeletons.
  • Milestone 2: Working prototype checked into the incubator supporting use cases #1, #2 and #3
  • Milestone 3: Working prototype checked into the incubator supporting with all methods implemented
  • Milestone 4: Unit tests exist, work, and are checked into SVN.
  • Milestone 5: Initial documentation exists.

7. Class Index

  • Zend_Service_37Signals_Basecamp_Exception
  • Zend_Service_37Signals_Basecamp

8. Use Cases

UC-01

Configure and instantiate web service object:

UC-02

Get title for each message in project:

UC-03

Create new milestone in project:

9. Class Skeletons

]]></ac:plain-text-body></ac:macro>

]]></ac:plain-text-body></ac:macro>

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. May 14, 2008

    <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>

    1. May 29, 2008

      <p>Ok, I will fill it out as soon as possible.</p>

  2. Jun 20, 2008

    <p>Looking good. Is it ready for community review yet? If so, please put it in the 'Ready for Review' section and announce to the fw-general list.</p>

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

  3. Jul 13, 2008

    <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>

  4. Jul 14, 2008

    <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>

    1. Jul 14, 2008

      <p>Well, totally. <ac:emoticon ac:name="wink" /></p>

      <p>I see your point about $_GET and $_POST though I assume most people have a layer between data manipulation and GPC (at least I hope). I use objects even from Zend_Db_Select etc, but I guess that all depends on your personal preference.</p>

      <p>I see your point about getting data and using the base class to actually set/write, I guess you are talking about convenience, right? Having all set'rs in one place. I am not sure I like that very much, but in any way thanks for working on this and thanks for taking my feedback into consideration.</p>

      1. Jul 29, 2008

        <p>I changed name of this class to Zend_Service_37Signals_Basecamp and I updated __construct() and setOptions() methods to accept Zend_Config objects as good as arrays. Thanks for your feedback <ac:emoticon ac:name="smile" /></p>

  5. Oct 31, 2008

    <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>

  6. Mar 18, 2009

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