Version 1 by Pádraic Brady
on Jul 07, 2009 17:32.

compared with
Version 2 by Pádraic Brady
on Jul 07, 2009 17:34.

This line was removed.
This word was removed. This word was added.
This line was added.

Changes (32)

View Page History
{info:title=New Proposal Template}
This page has been created from a template that uses "zones." To proceed:
{zone-template-instance:ZFDEV:Zend Proposal Zone Template}

# Edit the page
# Replace sample content within each zone-data tag with your own content
# Remove this notice
# Save the page
# When you are ready for community review, move this page to the [Ready for Review] section on the edit page.

{note:title=No placeholders allowed!}
Please do not create placeholders. Wait until you have sufficient content to replace all sample data in the proposal template before creating your proposal document.

{zone-template-instance:ZFPROP:Proposal Zone Template}

Zend_Magic Zend_Feed_Writer

[My Name|]


1.0 - 1 January 2008: Initial Draft.
0.1 - 08 July 2009

Zend_Magic is a simple component that reads my mind and generates code dynamically to do what I want.
h3. 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 on the DOM correctly, RDF support was non-existent (even now it's added by way of a patch which messes with the RSS namespaces), 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 eliminate any tasks needed to transfer your data into an Atom 1.0 or RSS 2.0 feed. And it should do this while maintaining a rigorous and unforgiving adherence to standards.


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 actively prevent the construction of malformed feeds. Two initial standards will be enforced: RSS 2.0 (including all current RSS Advisory Board 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). 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. 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.

* [Harry Houdini Wikipedia Entry|]
* [|]

Most requirements take the form of "foo will do ...." or "foo will not support ...", although different words and sentence structure might be used. Adding functionality to your proposal is requirements creep (bad), unless listed below. Discuss major changes with your team first, and then open a "feature improvement" issue against this component.
* 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
* MUST be capable of importing Zend_Feed_Reader objects for manipulation/editing

* This component *will* correctly reads a developers mind for intent and generate the right configuration file.
* The generated config file *will not* support XML, but will provide an extension point in the API.
* This component *will* use no more memory than twice the size of all data it contains.
* This component *will* include a factory method.
* This component *will not* allow subclassing. (i.e. when reviewed, we expect to see "final" keyword in code)
* This component *will* only generate data exports strictly complying with RFC 12345.
* This component *will* validate input data against formats supported by ZF component Foo.
* This component *will not* save any data using Zend_Cache or the filesystem. All transient data *will be* saved using Zend_Session.

* Zend_Exception

The component is instantiated with a mind-link that ...


Describe some intermediate state of this component in terms of design notes, additional material added to this page, and / code. Note any significant dependencies here, such as, "Milestone #3 can not be completed until feature Foo has been added to ZF component XYZ." Milestones will be required for acceptance of future proposals. They are not hard, and many times you will only need to think of the first three below.
* 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.

If a milestone is already done, begin the description with "\[DONE\]", like this:
* Milestone #: \[DONE\] Unit tests ...
* 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

* Zend_Magic_Exception Zend_Feed_Writer
* Zend_Magic (factory class)
* Zend_Magic_MindProbe Zend_Feed_Writer_FeedInterface
* Zend_Magic_MindProbe_Intent Zend_Feed_Writer_Feed_Rss
* Zend_Magic_Action Zend_Feed_Writer_Feed_Atom
* Zend_Magic_CodeGen Zend_Feed_Writer_EntryInterface
* Zend_Feed_Writer_Entry_Rss
* Zend_Feed_Writer_Entry_Atom
* Zend_Feed_Writer_Extension_FeedAbstract
* Zend_Feed_Writer_Extension_EntryAbstract
* Zend_Feed_Writer_Extension_DublinCore_Feed
* Zend_Feed_Writer_Extension_DublinCore_Entry
* Zend_Feed_Writer_Extension_Atom_Feed
* Zend_Feed_Writer_Extension_Atom_Entry
* Zend_Feed_Writer_Extension_Content_Entry
* Zend_Feed_Writer_Extension_WellFormedWeb_Feed
* Zend_Feed_Writer_Extension_Slash_Entry
* Zend_Feed_Writer_Extension_Syndication_Feed

Others may be determined during development


... (see good use cases book)
Use cases are currently being drafted.

class Zend_Magic_Exception extends Zend_Exception {}

class Zend_Magic {
Skeleton Classes will be published shortly. Please see Zend_Feed_Reader's application of Extensions, and it's API style as a similar related component.