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_Technorati Component Proposal

Proposed Component Name Zend_Service_Technorati
Developer Notes
Proposers Simone Carletti
Darby Felton, Zend liaison
Revision 1.0 - 4 February 2007: Proposal draft.
2.0 - 13 November 2007: Proposal approved, updated details. (wiki revision: 12)

Table of Contents

1. Overview

Zend_Service_Technorati provides an easy, intuitive and object oriented interface for using Technorati APIs.

Each API call has a 1:1 method in the Zend_Service_Technorati class.
Convenient methods may be created in order to make developer's life easier.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • This component will implement all available Technorati API calls with 1:1 naming convention.
  • This component will implement not-documented API calls from useful API services, for example KeyInfo.
  • This component will implement convenient calls to access complex data or properties.
  • This component will parse and return server responses as intuitive data objects.

4. Dependencies on Other Framework Components

  • Zend_Service_Exception
  • Zend_Rest_Client
  • Zend_Uri
  • Zend_Date

5. Theory of Operation

An instance of Zend_Service_Technorati object is created, with an unique Technorati API Key.
After that, you can use this instance to query Technorati search index with one of available Zend_Service_Technorati API methods.

Depending on query type, developer MUST provide mandatory parameters required by Technorati.
Optional parameters MAY be provided using an associative array.

6. Milestones / Tasks

Milestone 0: [DONE] develop release 0.1 alpha for testing
Milestone 1: [DONE] write component proposal
Milestone 2: [DONE] proposal acceptance
Milestone 3: [DONE] import release 0.1 alpha to incubator/lab svn
Milestone 4: [DONE] class development and improvements
Milestone 5: [DONE] write unit tests and debugging
Milestone 6: [DONE] write documentation

7. Class Index

  • Zend_Service_Technorati - core class
  • Zend_Service_Technorati_ResultSet - a base result set
  • Zend_Service_Technorati_Result - a base result
  • Zend_Service_Technorati_CosmosResultSet - a Cosmos query result set
  • Zend_Service_Technorati_CosmosResult - a Cosmos query result
  • ...
  • Zend_Service_Technorati_Author - each weblog has zero or more authors
  • Zend_Service_Technorati_Weblog - some queries returns weblog object along with other data
  • Zend_Service_Technorati_Key - a Technorati key, used for KeyInfo() query

Note. Due to Technorati API responses, each query should have a specific result set and result class.

8. Use Cases


Create a Zend_Service_Technorati instance


Retrieve key info


Retrieve Cosmos with default options, URL


Retrieve Cosmos with custom options, URL


Retrieve Cosmos XML response (useful for debugging purpose) with custom options

9. Class Skeletons

Core Object

Author Object

Weblog Object

Key Object

ResultSet Object

Result Object

Cosmos ResultSet Object (each service will have its own class)

Cosmos Result Object (each service will have its own class)



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

    <p>I don't really know Technorati's APIs, so my comments might be out of line, but:</p>

    <li>I don't see a reason to have a separate class for each result type, since you are using properties (or virtual properties) to access response values, you could have a single class for it.</li>

    <p>It's also quite probable that there are shared response properties (for example whether the request succeeded or not). I think that in your case having a single class with virtual properties might be better and simpler. </p>

    <p>If you have to have more than one class, I'd go with this structure:</p>

    <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
    Zend_Service_Technorati_Result (or Zend_Service_Technorati_Result_Abstract)

    +- Zend_Service_Technorati_Result_Cosmos
    +- Zend_Service_Technorati_Result_Foo
    +- ...

    <li>I also don't see why you need separate ResultSet classes - they all look like the same kind of iterators to me.</li>

    <li>Personally, since you're going to be doing reading mostly, I would use SimpleXML and not DOM - but I guess that this is a personal preference <ac:emoticon ac:name="wink" /></li>

    <p>Keep up the good work!</p>


    1. May 14, 2007

      <ac:macro ac:name="unmigrated-wiki-markup"><ac:plain-text-body><![CDATA[Hi Shahar,
      thanks for your feedback, I really appreciated it.

      Working with virtual properties was one of the architecture I analyzed at the beginning of this project.
      The biggest problem was to deal with responses without a common schema.
      For example it's quite difficult to find a shared class in order to satisfy both BlogPostTags and Tag requirements even if they talk about... tags.

      I had a look at Zend_Service_Yahoo library and I chose this way.
      I created a base class (you're right, it can be defined as abstract) and a structure like

      I identified shared objects and defined them as single classes.
      For instance, Cosmos, BlogPostTags and Tag responses include a "Blog" object


      • Implement SeekableIterator::current and
      • overwrites Zend_Service_Technorati_ResultSet::current()
      • @return Zend_Service_Technorati_CosmosResult Current Zend_Service_Technorati_Cosmos result
        public function current()
        Unknown macro: { return new Zend_Service_Technorati_CosmosResult($this->_results->item($this->_currentItem)); }
        Unknown macro: {/code}

      2. The second (big) issue is that Technorati returns the most unstandardized answers I ever seen.
      Depending on API request, it returns the same information inside different tags.
      For instance, have a look at Search and [Tag| requests.
      The first request returns the value of start parameter inside ranking tag

      while the second one inside start tag

      Consider that for other requests I had to read it from API call...
      Using this kind of ResultSet structure allows me to read and define per-request parameters inside child constructor.
      What do you think about this "workaround".

      Please, forgive me for this long answer but I would love to be sure to include all details "behind the scenes".

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

  2. Nov 06, 2007

    <ac:macro ac:name="note"><ac:parameter ac:name="title">Zend Comments</ac:parameter><ac:rich-text-body>
    <p>This proposal has been approved for incubator development under the following conditions:</p>

    <li>Objects used to encapsulate responses are currently using public properties, but these do not fit well for read-only values, since they can be modified. Instead, such properties should be made accessible through getProperty() and setProperty($value) methods, as applicable. As with public properties, this approach also enables automatic code completion for PHP editors that support it.</li>

    <li>Dependencies on other framework components should be reasonable. Obviously Zend_Rest_Client, Zend_Uri, and Zend_Service_Exception make sense, but ensure that the use of the filter and validation components is reasonable for the implementation.</li>

    1. Nov 12, 2007

      <p>Thanks Darby,<br />
      I've just committed the initial release that was stored on a personal SVN server.</p>

      <p>In the next days I'm going to change object properties and remove pointless dependencies.</p>