The architecture of
Zend_Feed_Writer is very simple. It has two
core sets of classes: data containers and renderers.
The containers include the
Zend_Feed_Writer_Entry classes. The Entry classes can be attached
to any Feed class. The sole purpose of these containers is to collect data about the
feed to generate using a simple interface of setter methods. These methods perform some
data validity testing. For example, it will validate any passed URIs,
dates, etc. These checks are not tied to any of the feed standards definitions. The
container objects also contain methods to allow for fast rendering and export of the
final feed, and these can be reused at will.
In addition to the main data container classes, there are two additional Atom 2.0
Zend_Feed_Writer_Deleted. The former implements Atom 2.0 source
elements which carry source feed metadata for a specific entry within an aggregate feed
(i.e. the current feed is not the entry's original source). The latter implements the
Atom Tombstones RFC allowing feeds to carry references to entries
which have been deleted.
While there are two main data container types, there are four renderers - two matching
container renderers per supported feed type. Each renderer accepts a container, and
based on its content attempts to generate valid feed markup. If the renderer is unable
to generate valid feed markup, perhaps due to the container missing an obligatory data
point, it will report this by throwing an
Exception. While it is
possible to ignore
Exceptions, this removes the default safeguard
of ensuring you have sufficient data set to render a wholly valid feed.
To explain this more clearly, you may construct a set of data containers for a feed where there is a Feed container, into which has been added some Entry containers and a Deleted container. This forms a data hierarchy resembling a normal feed. When rendering is performed, this hierarchy has its pieces passed to relevant renderers and the partial feeds (all DOMDocuments) are then pieced together to create a complete feed. In the case of Source or Deleted (Tomestone) containers, these are rendered only for Atom 2.0 and ignored for RSS.
Due to the system being divided between data containers and renderers, it can make Extensions somewhat interesting. A typical Extension offering namespaced feed and entry level elements, must itself reflect the exact same architecture, i.e. offer feed and entry level data containers, and matching renderers. There is, fortunately, no complex integration work required since all Extension classes are simply registered and automatically used by the core classes. We'll meet Extensions in more detail at the end of this section.