Zend Framework: Zend_Oembed Component Proposal
| Proposed Component Name | Zend_Oembed |
|---|---|
| Developer Notes | http://framework.zend.com/wiki/display/ZFDEV/Zend_Oembed |
| Proposers | Pawel Przeradowski |
| Revision | 0.1 - 13 May 2008: Initial creation. 0.2 - 14 May 2008: Outlining class interface. 0.2.1 - 13 June 2008: Updated adopters (wiki revision: 31) |
Table of Contents
1. Overview
Zend_Oembed family of classes is a component that can consume and produce oEmbed resources with simple and straightforward API. Zend_Oembed_Client reuses possibilities of Zend_Http_Client for obtaining oEmbed resources represented by Zend_Oembed_Resource instances. It furthermore provides view helpers for rendering oEmbed resources in XML or JSON format.
oEmbed is a protocol for easily obtaining and embedding third-party media. It relies on HTTP for transfer and provides XML or JSON encoded resources. Each resource is uniquely identified by it's URL. oEmbed provider publishes API endpoint URL and oEmbed consumers can query it by using appropriate resource URLs.
Example:
- API endpoint: http://www.filckr.com/services/oembed/
- Resource URL: http://www.flickr.com/photos/nicolasbdotnet/1840441618/
- Combined: http://www.flickr.com/services/oembed/?url=http://www.flickr.com/photos/nicolasbdotnet/1840441618/
- Response:
Early adopters:
- Flickr
- Viddler
- Twitter (oohembed)
- Qik
- YouTube (oohembed)
- Wikipedia (oohembed)
- IMDb (oohemebd)
- Amazon (oohemebd)
...
2. References
- oEmbed protocol specification
- Viddler oEmbed Wiki Page
- Ruby implementation
- oohEmbed - oEmbed compatible provider of HTML embed codes for various web sites
3. Component Requirements, Constraints, and Acceptance Criteria
- This component will consume both XML and JSON OEmbed resources
- This component will provide easy way of implementing OEmbed providers
- This component will include a factory methods for creating resources from arrays, XML, JSON, DOMNodes etc.
- This component will allow subclassing.
- This component will fallow oEmbed specification.
4. Dependencies on Other Framework Components
- Zend_Exception
- Zend_Http_Client
- Zend_Http_Response
- Zend_Json (optional)
5. Theory of Operation

6. Milestones / Tasks
- Milestone 1: design notes will be published here
- Milestone 2: Working prototype checked into the incubator supporting use cases #1, #2, ...
- Milestone 3: Working prototype checked into the incubator supporting use cases #3 and #4.
- Milestone 4: Unit tests exist, work, and are checked into SVN.
- Milestone 5: Initial documentation exists.
7. Class Index
- Zend_Service_Oembed_Exception
- Zend_Service_Oembed_Client
- Zend_Service_Oembed_Client_Exception
- Zend_Service_Oembed_Resource
- Zend_Service_Oembed_Resource_Exception
- Zend_View_Helper_OembedXml
- Zend_View_Helper_OembedJson
8. Use Cases
See some of use cases in cation
9. Class Skeletons
Pawel, it might be easier to get the feedback you're looking for if you move this to 'Ready for Review' and notify the community via the mailing lists.
,Wil
1.) I would suggest to follow the robustness priciple: yes, accept application/json and application/xml
2.) It is a client, leave it that way
3.) It represents a resource, more specifically a OEmbed resource, so Resource is fine
4.) I would think that even resources generated using fromXml/fromJson etc. pp. should be validated
5.) Zend_Service_Oembed. The first namespace is cluttered enough ![]()
6.) That's a tough question: does the standard say something about embedding HTML?
7.) I don't think so this helper is really needed. As far as I can see, the output generation will be as custom as custom can be, anyway
A few notes:
8.) I would like the resource class to be more stricts regarding its interface. Why not have explicit gettern for the standardized values?
9.) I don't think it is a good idea to let Zend_Service_Oembed extend the Zend_Http_Client class. Rather compisite it. This is also more correct from an OOD standpoint as "the oembed service client has HTTP client" instead "is a HTTP client". Who knows, maybe other transport layers will follow.
- Agreed
- OK
- I'll leave that way
- That's a nice idea - I'll do that
- Yeah - it might fit there better
- When you request a video or rich (which is simply requesting html fragment) you get html property in response. Specification says it's to consumer to deal with it. See UC4 in action for demonstration. I think I could include filterScripts option with default value true which would lead to stripping scripts, script urls and other threats.
- I agree
- I quite don't get idea. Current for eg. 'provider_name' I planned $this->getProperty('provider_name', 'opt_default_value'), echo $this->providerName, $this->providerName = $x; isset($this->providerName); I also thought of implementing iterable and countable but dont know if it's nice idea. Well of course I can add getProviderName but I fail to see advantage of that. Providers can also send their custom properties.
- Agreed. I'll rework it with composition.
Previously I outlined following factory methods inside Zend_Oembed_Resource:
fromUri($endpointUri, $resourceUri, $options)
fromHttpResponse($response, $filterScripts = true);
fromXml($xml, $filterScripts = true);
fromJson($json, $filterScripts = true);
fromArray($properties)
I also declared __constructor() protected to prevent direct construction
I think I could make __constructor public and make it work as fromArray and drop fromArray static call. What do you think?
Also when performing validation against incoming resources is it natural to wrap that funcitonality into subclass of Zend_Validate_Abstract ?
ZF Home Page
Code Browser
Wiki Dashboard
I need your help on some implementation/design/naming decisions.