Skip to end of metadata
Go to start of metadata

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: 22)

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

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

9 Comments

comments.show.hide

  1. May 14, 2008

    Wil Sinclair

    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.

    Thanks.
    ,Wil

    1. May 29, 2008

      Wojciech Naruniec

      Ok, I will fill it out as soon as possible.

  2. Jun 20, 2008

    Wil Sinclair

    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.

    Thanks!
    ,Wil

  3. Jul 13, 2008

    Till Klampaeckel

    Damn wiki just ate my reply! >

    Anyway. I hope I remembered all of what I had originally.
    Those are all suggestions and strictly IMHO.

    In short, I'd like a more object oriented approach, for example:

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

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

    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.

  4. Jul 14, 2008

    Wojciech Naruniec

    Thanks for your feedback!

    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.

    You can provide Zend_Config instance to Zend_Service_Basecamp::__construct() method by calling toArray() method:

    I would like to leave this decision over until Zend_Config Usage in Constructors and Factories proposal will be reviewed. However, you can change your options using setOptions() method to reuse object later.

    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.

    1. Jul 14, 2008

      Till Klampaeckel

      Well, totally.

      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.

      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.

      1. Jul 29, 2008

        Wojciech Naruniec

        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

  5. Oct 31, 2008

    Ralph Schindler

    Zend Official Response
    This is accepted to Zend Extras Incubator

    Suggested Changes:

    • Move the constants into protected property so that the uris are not part of the
      exposed api, and this will make it easier to maintain a versioned api when/if basecamp comes to that.

  6. Mar 18, 2009

    Wil Sinclair

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