This line was removed.
This word was removed. This word was added.
This line was added.
Changes (3)View Page History
h35. 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_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.
h5. 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 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.