Skip to end of metadata
Go to start of metadata

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:
Early adopters:
  • Flickr
  • Viddler
  • Twitter (oohembed)
  • Qik
  • YouTube (oohembed)
  • Wikipedia (oohembed)
  • IMDb (oohemebd)
  • Amazon (oohemebd)
    ...

2. References

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

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

6 Comments

comments.show.hide

  1. May 13, 2008

    Pawel Przeradowski

    I need your help on some implementation/design/naming decisions.

    1. oEmbed specification states that Content-Types for XML and JSON reponses are text/xml and application/json. Should application/xml and text/javascript be also allowed?
    2. What's the best name for HTTP client class. Zend_Oembed_Consumer, Zend_Oembed_Client... ?
    3. What's the best name fot oEmbed resource class. Zend_Oembed_Object, Zend_Oembed_Resource, Zend_Oembed_Medium... ?
    4. oEmbed specification states that some properties are required. Should any resource coming from HTTP be validated against those constraints?
    5. Should it be Zend_Oembed_* or Zend_Service_Oembed_* ?
    6. Should it include possibility to filter out content which may lead XSS attacks?
    7. There certainly is a need for Zend_View_Helper_OembedXml and Zend_View_Helper_OembedJson helpers. Is there also a need for Zend_View_Helper_OembedHtml that would output appropriate markup based on type property? If yes how should it be implemented to be flexible? Decorator pattern?

    1. May 14, 2008

      Wil Sinclair

      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

    2. May 15, 2008

      Lars Strojny

      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.

      1. May 16, 2008

        Pawel Przeradowski

        1. Agreed
        2. OK
        3. I'll leave that way
        4. That's a nice idea - I'll do that
        5. Yeah - it might fit there better
        6. 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.
        7. I agree
        8. 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.
        9. Agreed. I'll rework it with composition.

  2. May 16, 2008

    Pawel Przeradowski

    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 ?

  3. Feb 08, 2011

    Dolf Schimmel (Freeaqingme)

    Archiving this proposal, feel free to recover it when you want to work on it again. For more details see this email.