Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current  |   View Page History

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Zend Framework: Zend_Feed_Writer Component Proposal

Proposed Component Name Zend_Feed_Writer
Developer Notes http://framework.zend.com/wiki/display/ZFDEV/Zend_Feed_Writer
Proposers Pádraic Brady
Revision 1.1 - 20 September 2009 (wiki revision: 5)

Table of Contents

1. Overview

Why Propose A Replacement For Zend_Feed's Feed Creation Features?

Back in 2008, I proposed Zend_Feed_Reader as a means to layer a user friendly API on top of Zend_Feed when consuming feeds. In a short time, the proposal evolved after more and more Zend_Feed inconsistencies were discovered. For example, there was no consistent API once you left the basic usage, namespaces were not handled correctly, RDF support was non-existent (the current solution muddles namespaces even more), and in brief it forced developers to write an abstraction layer on top of it to make it work.

Zend_Feed_Reader took a different approach, targeting an implementation which used the DOM and XPath queries coupled with an internal implementation which was capable of understanding the various RSS and Atom standards. This was all built around a simple intuitive and extendable API to eliminate the guesswork users needed as well as the need to implement abstraction layers which differed wildly across projects. Zend_Feed_Reader is now a standalone component with no ties to Zend_Feed.

Zend_Feed_Writer follows an identical ideology - focusing on getting the job done with minimal effort using as simple an API as possible. The component should make transferring your data into an Atom 1.0 or RSS 2.0 feed painless. And it should do this while maintaining a rigorous and unforgiving adherence to standards.

About Zend_Feed_Writer

The main differences from Zend_Feed will be very obvious. Zend_Feed_Writer will present a fixed method based API which must be clearly defined either in the core classes, or the set of currently loaded Extensions. These will help define namespaces, element positioning and syntax, and actively prevent the construction of malformed feeds. Two initial standards will be enforced: RSS 2.0 (specifically the RSS Advisory Board 2.0.11 recommendations) and Atom 1.0. The full range of Atom 1.0 will be available, as standard, as an RSS Extension where warranted (e.g. including URI's for an RSS feed's source XML which borrows from the Atom namespace). This will contrast with Zend_Feed's reliance on chained property assignments which require greater knowledge of the standards, and are not easily reduced to common steps for both RSS and Atom.

Zend_Feed_Writer will not utilise templating. Templating is a fast, effective solution for building feeds but it's also restrictive, encourages assumptions as to namespaces and positioning, and relies on templated strings which are prone to error and add to maintenance problems. Instead, Zend_Feed_Writer will build its feeds from scratch using the PHP DOM which at the end of the day requires less base code since everything is condensed into DOM operations. DOM access will be available at all levels for manipulation outside of Zend_Feed_Writer (just as Zend_Feed_Reader offers easy access to Feed/Entry level DOMElement objects). It also ensures user Extensions have complete access to manipulate a feed in progress as needed.

In short, Zend_Feed_Writer is the obvious missing partner to Zend_Feed_Reader, completing support for consuming and building feeds.

2. References

Basic implementation with Atom support

3. Component Requirements, Constraints, and Acceptance Criteria

  • MUST understand the valid structure of RSS 2.0 and Atom 1.0 documents
  • MUST enforce valid structures raising Exceptions on illegal actions or when missing elements are detected
  • MUST allow the API to be extended via Extensions
  • MUST present an API which is consistent whether the feed being built is RSS or Atom
  • MUST expose the underlying parent DOMDocument or DOMElement object for external manipulation
  • MAY be capable of importing Zend_Feed_Reader objects for manipulation/editing (preferred future feature)

4. Dependencies on Other Framework Components

Zend_Http_Client
Zend_Cache
Zend_Loader_PluginLoader

5. Theory of Operation

Since neither RSS or Atom assign any significance to the order of elements, there is no need for any complex wiring. So the simplest solution is to implement Zend_Feed_Writer as two branches of classes. The first implement a fixed method API, e.g. methods like setTitle() and getTitle(). In isolation, these classes are nothing more than container objects which can be manipulated at any time. The real work is performed by the second branch of classes implementing Zend_Feed_Writer_RendererInterface. These, including all Renderers registered from Extensions, will form a simple render queue with a DOMDocument object representing either a Feed or Entry passed along the queue so each Renderer can append additional elements or edit others. The final result is then constructed by importing all root Entry elements into the Feed level DOM. The term "Renderer" is probably not even the most suitable one since the actual XML string produced is a simple saveXML() call on the final DOMDocument, but it will suffice for now.

6. Milestones / Tasks

  • Milestone 1: Publish and have proposal approved with Zend comments to resolve
  • Milestone 2: Complete initial component with unit tests
  • Milestone 3: Complete testing against a selection of web-based/desktop feed readers
  • Milestone 4: Verify that code operates under PHP 5.3/6.0-dev
  • Milestone 5: Complete documentation

7. Class Index

  • Zend_Feed_Writer
  • Zend_Feed_Writer_Entry
  • Zend_Feed_Writer_RendererInterface
  • Zend_Feed_Writer_Renderer_Feed_Rss
  • Zend_Feed_Writer_Renderer_Feed_Atom
  • Zend_Feed_Writer_Renderer_Entry_Rss
  • Zend_Feed_Writer_Renderer_Entry_Atom
  • Zend_Feed_Writer_Renderer_Extension_FeedAbstract
  • Zend_Feed_Writer_Renderer_Extension_EntryAbstract
    Others may be determined during development

8. Use Cases

Full working example:

Output from the above:

9. Class Skeletons

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

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