Zend Framework: Zend_Service_Technorati Component Proposal
| Proposed Component Name | Zend_Service_Technorati |
|---|---|
| Developer Notes | http://framework.zend.com/wiki/display/ZFDEV/Zend_Service_Technorati |
| 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: 11) |
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
| UC-01 |
|---|
Create a Zend_Service_Technorati instance
| UC-02 |
|---|
Retrieve key info
| UC-03 |
|---|
Retrieve Cosmos with default options, URL www.simonecarletti.com/blog
| UC-04 |
|---|
Retrieve Cosmos with custom options, URL www.simonecarletti.com/blog
| UC-05 |
|---|
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)
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|http://technorati.com/developers/api/tag.html 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
| Zend Comments This proposal has been approved for incubator development under the following conditions:
|
ZF Home Page
Issue Tracker
SVN Browser
Wiki Dashboard
I don't really know Technorati's APIs, so my comments might be out of line, but:
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.
If you have to have more than one class, I'd go with this structure:
Keep up the good work!
Shahar.