| blob | 90954551da1d5eda4a6e514ee40872ff19da49ce |
1 <?xml version="1.0" encoding="UTF-8"?>
2 <!-- Reviewed: no -->
3 <sect1 id="zend.feed.writer">
4 <title>Zend_Feed_Writer</title>
6 <sect2 id="zend.feed.writer.introduction">
7 <title>Introduction</title>
9 <para>
10 <classname>Zend_Feed_Writer</classname> is the sibling component to
11 <classname>Zend_Feed_Reader</classname> responsible for generating feeds for output. It
12 supports the Atom 1.0 specification (RFC 4287) and <acronym>RSS</acronym> 2.0 as
13 specified by the <acronym>RSS</acronym> Advisory Board (<acronym>RSS</acronym> 2.0.11).
14 It does not deviate from these standards. It does, however, offer a simple Extension
15 system which allows for any extension and module for either of these two specifications
16 to be implemented if they are not provided out of the box.
17 </para>
19 <para>
20 In many ways, <classname>Zend_Feed_Writer</classname> is the inverse of
21 <classname>Zend_Feed_Reader</classname>. Where <classname>Zend_Feed_Reader</classname>
22 focuses on providing an easy to use architecture fronted by getter methods,
23 <classname>Zend_Feed_Writer</classname> is fronted by similarly named setters or
24 mutators. This ensures the <acronym>API</acronym> won't pose a learning curve to anyone
25 familiar with <classname>Zend_Feed_Reader</classname>.
26 </para>
28 <para>
29 As a result of this design, the rest may even be obvious. Behind the scenes, data set on
30 any <classname>Zend_Feed_Writer</classname> Data Container object is translated at
31 render time onto a DOMDocument object using the necessary feed elements. For each
32 supported feed type there is both an Atom 1.0 and <acronym>RSS</acronym> 2.0 renderer.
33 Using a DOMDocument class rather than a templating solution has numerous advantages,
34 the most obvious being the ability to export the DOMDocument for
35 additional processing and relying on <acronym>PHP</acronym> <acronym>DOM</acronym> for
36 correct and valid rendering.
37 </para>
39 <para>
40 As with <classname>Zend_Feed_Reader</classname>, <classname>Zend_Feed_Writer</classname>
41 is a standalone replacement for <classname>Zend_Feed</classname>'s Builder architecture
42 and is not compatible with those classes.
43 </para>
44 </sect2>
46 <sect2 id="zend.feed.writer.architecture">
47 <title>Architecture</title>
49 <para>
50 The architecture of <classname>Zend_Feed_Writer</classname> is very simple. It has two
51 core sets of classes: data containers and renderers.
52 </para>
54 <para>
55 The containers include the <classname>Zend_Feed_Writer_Feed</classname> and
56 <classname>Zend_Feed_Writer_Entry</classname> classes. The Entry classes can be attached
57 to any Feed class. The sole purpose of these containers is to collect data about the
58 feed to generate using a simple interface of setter methods. These methods perform some
59 data validity testing. For example, it will validate any passed <acronym>URI</acronym>s,
60 dates, etc. These checks are not tied to any of the feed standards definitions. The
61 container objects also contain methods to allow for fast rendering and export of the
62 final feed, and these can be reused at will.
63 </para>
65 <para>
66 In addition to the main data container classes, there are two additional Atom 2.0
67 specific classes. <classname>Zend_Feed_Writer_Source</classname> and
68 <classname>Zend_Feed_Writer_Deleted</classname>. The former implements Atom 2.0 source
69 elements which carry source feed metadata for a specific entry within an aggregate feed
70 (i.e. the current feed is not the entry's original source). The latter implements the
71 Atom Tombstones RFC allowing feeds to carry references to entries which have been
72 deleted.
73 </para>
75 <para>
76 While there are two main data container types, there are four renderers - two matching
77 container renderers per supported feed type. Each renderer accepts a container, and
78 based on its content attempts to generate valid feed markup. If the renderer is unable
79 to generate valid feed markup, perhaps due to the container missing an obligatory data
80 point, it will report this by throwing an <classname>Exception</classname>. While it is
81 possible to ignore <classname>Exception</classname>s, this removes the default safeguard
82 of ensuring you have sufficient data set to render a wholly valid feed.
83 </para>
85 <para>
86 To explain this more clearly, you may construct a set of data containers for a feed
87 where there is a Feed container, into which has been added some Entry containers and a
88 Deleted container. This forms a data hierarchy resembling a normal feed. When rendering
89 is performed, this hierarchy has its pieces passed to relevant renderers and the partial
90 feeds (all DOMDocuments) are then pieced together to create a complete feed. In the case
91 of Source or Deleted (Tomestone) containers, these are rendered only for Atom 2.0 and
92 ignored for RSS.
93 </para>
95 <para>
96 Due to the system being divided between data containers and renderers, it can make
97 Extensions somewhat interesting. A typical Extension offering namespaced feed and entry
98 level elements, must itself reflect the exact same architecture, i.e. offer feed and
99 entry level data containers, and matching renderers. There is, fortunately, no complex
100 integration work required since all Extension classes are simply registered and
101 automatically used by the core classes. We'll meet Extensions in more detail at the end
102 of this section.
103 </para>
104 </sect2>
106 <sect2 id="zend.feed.writer.getting.started">
107 <title>Getting Started</title>
109 <para>
110 Using <classname>Zend_Feed_Writer</classname> is as simple as setting data and
111 triggering the renderer. Here is an example to generate a minimal Atom 1.0 feed.
112 As this demonstrates, each feed/entry uses a separate data container.
113 </para>
115 <programlisting language="php"><![CDATA[
116 /**
117 * Create the parent feed
118 */
119 $feed = new Zend_Feed_Writer_Feed;
120 $feed->setTitle('Paddy\'s Blog');
121 $feed->setLink('http://www.example.com');
122 $feed->setFeedLink('http://www.example.com/atom', 'atom');
123 $feed->addAuthor(array(
124 'name' => 'Paddy',
125 'email' => 'paddy@example.com',
126 'uri' => 'http://www.example.com',
127 ));
128 $feed->setDateModified(time());
129 $feed->addHub('http://pubsubhubbub.appspot.com/');
131 /**
132 * Add one or more entries. Note that entries must
133 * be manually added once created.
134 */
135 $entry = $feed->createEntry();
136 $entry->setTitle('All Your Base Are Belong To Us');
137 $entry->setLink('http://www.example.com/all-your-base-are-belong-to-us');
138 $entry->addAuthor(array(
139 'name' => 'Paddy',
140 'email' => 'paddy@example.com',
141 'uri' => 'http://www.example.com',
142 ));
143 $entry->setDateModified(time());
144 $entry->setDateCreated(time());
145 $entry->setDescription('Exposing the difficultly of porting games to English.');
146 $entry->setContent(
147 'I am not writing the article. The example is long enough as is ;).'
148 );
149 $feed->addEntry($entry);
151 /**
152 * Render the resulting feed to Atom 1.0 and assign to $out.
153 * You can substitute "atom" with "rss" to generate an RSS 2.0 feed.
154 */
155 $out = $feed->export('atom');
156 ]]></programlisting>
158 <para>
159 The output rendered should be as follows:
160 </para>
162 <programlisting language="xml"><![CDATA[
163 <?xml version="1.0" encoding="utf-8"?>
164 <feed xmlns="http://www.w3.org/2005/Atom">
165 <title type="text">Paddy's Blog</title>
166 <subtitle type="text">Writing about PC Games since 176 BC.</subtitle>
167 <updated>2009-12-14T20:28:18+00:00</updated>
168 <generator uri="http://framework.zend.com" version="1.10.0alpha">
169 Zend_Feed_Writer
170 </generator>
171 <link rel="alternate" type="text/html" href="http://www.example.com"/>
172 <link rel="self" type="application/atom+xml"
173 href="http://www.example.com/atom"/>
174 <id>http://www.example.com</id>
175 <author>
176 <name>Paddy</name>
177 <email>paddy@example.com</email>
178 <uri>http://www.example.com</uri>
179 </author>
180 <link rel="hub" href="http://pubsubhubbub.appspot.com/"/>
181 <entry>
182 <title type="html"><![CDATA[All Your Base Are Belong To
183 Us]]]]><![CDATA[></title>
184 <summary type="html">
185 <![CDATA[Exposing the difficultly of porting games to
186 English.]]]]><![CDATA[>
187 </summary>
188 <published>2009-12-14T20:28:18+00:00</published>
189 <updated>2009-12-14T20:28:18+00:00</updated>
190 <link rel="alternate" type="text/html"
191 href="http://www.example.com/all-your-base-are-belong-to-us"/>
192 <id>http://www.example.com/all-your-base-are-belong-to-us</id>
193 <author>
194 <name>Paddy</name>
195 <email>paddy@example.com</email>
196 <uri>http://www.example.com</uri>
197 </author>
198 <content type="html">
199 <![CDATA[I am not writing the article.
200 The example is long enough as is ;).]]]]><![CDATA[>
201 </content>
202 </entry>
203 </feed>
204 ]]></programlisting>
206 <para>
207 This is a perfectly valid Atom 1.0 example. It should be noted that omitting an
208 obligatory point of data, such as a title, will trigger an
209 <classname>Exception</classname> when rendering as Atom 1.0. This will differ for
210 <acronym>RSS</acronym> 2.0 since a title may be omitted so long as a description is
211 present. This gives rise to Exceptions that differ between the two standards depending
212 on the renderer in use. By design, <classname>Zend_Feed_Writer</classname> will not
213 render an invalid feed for either standard unless the end-user deliberately elects to
214 ignore all Exceptions. This built in safeguard was added to ensure users without
215 in-depth knowledge of the relevant specifications have a bit less to worry about.
216 </para>
217 </sect2>
219 <sect2 id="zend.feed.writer.setting.feed.data.points">
220 <title>Setting Feed Data Points</title>
222 <para>
223 Before you can render a feed, you must first setup the data necessary for
224 the feed being rendered. This utilises a simple setter style <acronym>API</acronym>
225 which doubles as an initial method for validating the data being set. By design, the
226 <acronym>API</acronym> closely matches that for <classname>Zend_Feed_Reader</classname>
227 to avoid undue confusion and uncertainty.
228 </para>
230 <note>
231 <para>Users have commented that the lack of a simple array based notation for input data
232 gives rise to lengthy tracts of code. This will be addressed in a future release.</para>
233 </note>
235 <para>
236 <classname>Zend_Feed_Writer</classname> offers this <acronym>API</acronym> via its data
237 container classes <classname>Zend_Feed_Writer_Feed</classname> and
238 <classname>Zend_Feed_Writer_Entry</classname> (not to mention the Atom 2.0 specific
239 and Extension classes). These classes merely store
240 all feed data in a type-agnostic manner, meaning you may reuse any data
241 container with any renderer without requiring additional work. Both classes
242 are also amenable to Extensions, meaning that an Extension may define its own
243 container classes which are registered to the base container classes as extensions, and
244 are checked when any method call triggers the base container's
245 <methodname>__call()</methodname> method.
246 </para>
248 <para>
249 Here's a summary of the Core <acronym>API</acronym> for Feeds. You should note it
250 comprises not only the basic <acronym>RSS</acronym> and Atom standards, but also
251 accounts for a number of included Extensions bundled with
252 <classname>Zend_Feed_Writer</classname>. The naming of these
253 Extension sourced methods remain fairly generic - all Extension
254 methods operate at the same level as the Core <acronym>API</acronym> though we do allow
255 you to retrieve any specific Extension object separately if required.
256 </para>
258 <para>
259 The Feed Level <acronym>API</acronym> for data is contained in
260 <classname>Zend_Feed_Writer_Feed</classname>. In addition to the <acronym>API</acronym>
261 detailed below, the class also implements the <classname>Countable</classname> and
262 <classname>Iterator</classname> interfaces.
263 </para>
265 <table>
266 <title>Feed Level API Methods</title>
268 <tgroup cols="2">
269 <tbody>
270 <row>
271 <entry><methodname>setId()</methodname></entry>
273 <entry>
274 Set a unique ID associated with this feed. For Atom 1.0
275 this is an atom:id element, whereas for <acronym>RSS</acronym> 2.0 it
276 is added as a guid element. These are optional so long as a link is
277 added, i.e. the link is set as the ID.
278 </entry>
279 </row>
281 <row>
282 <entry><methodname>setTitle()</methodname></entry>
283 <entry>Set the title of the feed.</entry>
284 </row>
286 <row>
287 <entry><methodname>setDescription()</methodname></entry>
288 <entry>Set the text description of the feed.</entry>
289 </row>
291 <row>
292 <entry><methodname>setLink()</methodname></entry>
294 <entry>
295 Set a <acronym>URI</acronym> to the <acronym>HTML</acronym> website
296 containing the same or
297 similar information as this feed (i.e. if the feed is from a blog,
298 it should provide the blog's <acronym>URI</acronym> where the
299 <acronym>HTML</acronym> version of the entries can be read).
300 </entry>
301 </row>
303 <row>
304 <entry><methodname>setFeedLinks()</methodname></entry>
306 <entry>
307 Add a link to an <acronym>XML</acronym> feed, whether the feed being
308 generated or an alternate <acronym>URI</acronym> pointing to the same
309 feed but in a different format. At a minimum, it is recommended to
310 include a link to the feed being generated so it has an identifiable
311 final <acronym>URI</acronym> allowing a client to track its location
312 changes without necessitating constant redirects. The parameter is an
313 array of arrays, where each sub-array contains the keys "type" and
314 "uri". The type should be one of "atom", "rss", or "rdf".
315 </entry>
316 </row>
318 <row>
319 <entry><methodname>addAuthors()</methodname></entry>
321 <entry>
322 Sets the data for authors. The parameter is an array of arrays
323 where each sub-array may contain the keys "name", "email" and
324 "uri". The "uri" value is only applicable for Atom feeds since
325 <acronym>RSS</acronym> contains no facility to show it. For
326 <acronym>RSS</acronym> 2.0, rendering will create two elements - an
327 author element containing the email reference with the name in brackets,
328 and a Dublin Core creator element only containing the name.
329 </entry>
330 </row>
332 <row>
333 <entry><methodname>addAuthor()</methodname></entry>
335 <entry>
336 Sets the data for a single author following the same
337 array format as described above for a single sub-array.
338 </entry>
339 </row>
341 <row>
342 <entry><methodname>setDateCreated()</methodname></entry>
344 <entry>
345 Sets the date on which this feed was created. Generally
346 only applicable to Atom where it represents the date the resource
347 described by an Atom 1.0 document was created. The expected parameter
348 may be a <acronym>UNIX</acronym> timestamp or a
349 <classname>Zend_Date</classname> object.
350 </entry>
351 </row>
353 <row>
354 <entry><methodname>setDateModified()</methodname></entry>
356 <entry>
357 Sets the date on which this feed was last modified. The expected
358 parameter may be a <acronym>UNIX</acronym> timestamp or a
359 <classname>Zend_Date</classname> object.
360 </entry>
361 </row>
363 <row>
364 <entry><methodname>setLanguage()</methodname></entry>
366 <entry>
367 Sets the language of the feed. This will be omitted unless set.
368 </entry>
369 </row>
371 <row>
372 <entry><methodname>getGenerator()</methodname></entry>
374 <entry>
375 Allows the setting of a generator. The parameter should be an
376 array containing the keys "name", "version" and "uri". If omitted
377 a default generator will be added referencing
378 <classname>Zend_Feed_Writer</classname>, the current Zend Framework
379 version and the Framework's <acronym>URI</acronym>.
380 </entry>
381 </row>
383 <row>
384 <entry><methodname>setCopyright()</methodname></entry>
385 <entry>Sets a copyright notice associated with the feed.</entry>
386 </row>
388 <row>
389 <entry><methodname>addHubs()</methodname></entry>
391 <entry>
392 Accepts an array of Pubsubhubbub Hub Endpoints to be rendered in
393 the feed as Atom links so that PuSH Subscribers may subscribe to
394 your feed. Note that you must implement a Pubsubhubbub Publisher in
395 order for real-time updates to be enabled. A Publisher may be
396 implemented using
397 <classname>Zend_Feed_Pubsubhubbub_Publisher</classname>.
398 The method <methodname>addHub()</methodname> allows adding
399 a single hub at a time.
400 </entry>
401 </row>
403 <row>
404 <entry><methodname>addCategories()</methodname></entry>
406 <entry>
407 Accepts an array of categories for rendering, where each element is
408 itself an array whose possible keys include "term", "label" and
409 "scheme". The "term" is a typically a category name suitable for
410 inclusion in a <acronym>URI</acronym>. The "label" may be a human
411 readable category name supporting special characters (it is HTML encoded
412 during rendering) and is a required key. The "scheme" (called the domain
413 in <acronym>RSS</acronym>) is optional but must be a valid
414 <acronym>URI</acronym>.
415 The method <methodname>addCategory()</methodname> allows adding
416 a single category at a time.
417 </entry>
418 </row>
420 <row>
421 <entry><methodname>createEntry()</methodname></entry>
422 <entry>Returns a new instance of <classname>Zend_Feed_Writer_Entry
423 </classname>. This is the Entry level data container. New entries
424 are not automatically assigned to the current feed, so you
425 must explicitly call <methodname>addEntry()</methodname>
426 to add the entry for rendering.</entry>
427 </row>
429 <row>
430 <entry><methodname>addEntry()</methodname></entry>
431 <entry>Adds an instance of <classname>Zend_Feed_Writer_Entry
432 </classname> to the current feed container for rendering.</entry>
433 </row>
435 <row>
436 <entry><methodname>createTombstone()</methodname></entry>
437 <entry>Returns a new instance of <classname>Zend_Feed_Writer_Deleted
438 </classname>. This is the Atom 2.0 Tombstone level data container. New
439 entries are not automatically assigned to the current feed, so you
440 must explicitly call <methodname>addTombstone()</methodname>
441 to add the deleted entry for rendering.</entry>
442 </row>
444 <row>
445 <entry><methodname>addTombstone()</methodname></entry>
446 <entry>Adds an instance of <classname>Zend_Feed_Writer_Deleted
447 </classname> to the current feed container for rendering.</entry>
448 </row>
450 <row>
451 <entry><methodname>removeEntry()</methodname></entry>
452 <entry>Accepts a parameter indicating an array index of the
453 entry to remove from the feed.</entry>
454 </row>
456 <row>
457 <entry><methodname>export()</methodname></entry>
458 <entry>Exports the entire data hierarchy to an XML feed. The method
459 has two parameters. The first is the feed type, one of "atom"
460 or "rss". The second is an optional boolean to set whether
461 Exceptions are thrown. The default is TRUE.</entry>
462 </row>
463 </tbody>
464 </tgroup>
465 </table>
467 <note>
468 <para>
469 In addition to these setters, there are also matching getters to retrieve data from
470 the Entry data container.
471 </para>
472 </note>
474 <!-- remaining feed stuff -->
476 </sect2>
478 <sect2 id="zend.feed.writer.setting.entry.data.points">
479 <title>Setting Entry Data Points</title>
481 <para>
482 Here's a summary of the Core <acronym>API</acronym> for Entries and Items. You should
483 note it comprises not only the basic <acronym>RSS</acronym> and Atom standards, but
484 also accounts for a number of included Extensions bundled with
485 <classname>Zend_Feed_Writer</classname>. The naming of these
486 Extension sourced methods remain fairly generic - all Extension
487 methods operate at the same level as the Core <acronym>API</acronym> though we do allow
488 you to retrieve any specific Extension object separately if required.
489 </para>
491 <para>
492 The Entry Level <acronym>API</acronym> for data is contained in
493 <classname>Zend_Feed_Writer_Entry</classname>.
494 </para>
496 <table>
497 <title>Entry Level API Methods</title>
499 <tgroup cols="2">
500 <tbody>
501 <row>
502 <entry><methodname>setId()</methodname></entry>
504 <entry>
505 Set a unique ID associated with this entry. For Atom 1.0
506 this is an atom:id element, whereas for <acronym>RSS</acronym> 2.0 it is
507 added as a guid element. These are optional so long as a link is
508 added, i.e. the link is set as the ID.
509 </entry>
510 </row>
512 <row>
513 <entry><methodname>setTitle()</methodname></entry>
514 <entry>Set the title of the entry.</entry>
515 </row>
517 <row>
518 <entry><methodname>setDescription()</methodname></entry>
519 <entry>Set the text description of the entry.</entry>
520 </row>
522 <row>
523 <entry><methodname>setContent()</methodname></entry>
524 <entry>Set the content of the entry.</entry>
525 </row>
527 <row>
528 <entry><methodname>setLink()</methodname></entry>
530 <entry>
531 Set a <acronym>URI</acronym> to the <acronym>HTML</acronym> website
532 containing the same or
533 similar information as this entry (i.e. if the feed is from a blog,
534 it should provide the blog article's <acronym>URI</acronym> where the
535 <acronym>HTML</acronym> version of the entry can be read).
536 </entry>
537 </row>
539 <row>
540 <entry><methodname>setFeedLinks()</methodname></entry>
542 <entry>
543 Add a link to an <acronym>XML</acronym> feed, whether the feed being
544 generated or an alternate <acronym>URI</acronym> pointing to the same
545 feed but in a different format. At a minimum, it is recommended to
546 include a link to the feed being generated so it has an identifiable
547 final <acronym>URI</acronym> allowing a client to track its location
548 changes without necessitating constant redirects. The parameter is an
549 array of arrays, where each sub-array contains the keys "type" and
550 "uri". The type should be one of "atom", "rss", or "rdf". If a type is
551 omitted, it defaults to the type used when rendering the feed.
552 </entry>
553 </row>
555 <row>
556 <entry><methodname>addAuthors()</methodname></entry>
558 <entry>
559 Sets the data for authors. The parameter is an array of arrays
560 where each sub-array may contain the keys "name", "email" and
561 "uri". The "uri" value is only applicable for Atom feeds since
562 <acronym>RSS</acronym> contains no facility to show it. For
563 <acronym>RSS</acronym> 2.0, rendering will create two elements - an
564 author element containing the email reference with the name in brackets,
565 and a Dublin Core creator element only containing the name.
566 </entry>
567 </row>
569 <row>
570 <entry><methodname>addAuthor()</methodname></entry>
572 <entry>
573 Sets the data for a single author following the same
574 format as described above for a single sub-array.
575 </entry>
576 </row>
578 <row>
579 <entry><methodname>setDateCreated()</methodname></entry>
581 <entry>
582 Sets the date on which this feed was created. Generally
583 only applicable to Atom where it represents the date the resource
584 described by an Atom 1.0 document was created. The expected parameter
585 may be a <acronym>UNIX</acronym> timestamp or a
586 <classname>Zend_Date</classname> object. If omitted, the date
587 used will be the current date and time.
588 </entry>
589 </row>
591 <row>
592 <entry><methodname>getDateModified()</methodname></entry>
594 <entry>
595 Sets the date on which this feed was last modified. The expected
596 parameter may be a <acronym>UNIX</acronym> timestamp or a
597 <classname>Zend_Date</classname> object. If omitted, the date
598 used will be the current date and time.
599 </entry>
600 </row>
602 <row>
603 <entry><methodname>setCopyright()</methodname></entry>
604 <entry>Sets a copyright notice associated with the feed.</entry>
605 </row>
607 <row>
608 <entry><methodname>setCategories()</methodname></entry>
610 <entry>
611 Accepts an array of categories for rendering, where each element is
612 itself an array whose possible keys include "term", "label" and
613 "scheme". The "term" is a typically a category name suitable for
614 inclusion in a <acronym>URI</acronym>. The "label" may be a human
615 readable category name supporting special characters (it is encoded
616 during rendering) and is a required key. The "scheme" (called the domain
617 in <acronym>RSS</acronym>) is optional but must be a valid
618 <acronym>URI</acronym>.
619 </entry>
620 </row>
622 <row>
623 <entry><methodname>setCommentCount()</methodname></entry>
625 <entry>
626 Sets the number of comments associated with this entry. Rendering
627 differs between <acronym>RSS</acronym> and Atom 2.0 depending
628 on the element/attribute needed.
629 </entry>
630 </row>
632 <row>
633 <entry><methodname>setCommentLink()</methodname></entry>
635 <entry>
636 Seta a link to a HTML page containing comments associated with this
637 entry.
638 </entry>
639 </row>
641 <row>
642 <entry><methodname>setCommentFeedLink()</methodname></entry>
644 <entry>
645 Sets a link to a XML feed containing comments associated with this
646 entry. The parameter is an array containing the keys "uri" and "type",
647 where the type is one of "rdf", "rss" or "atom".
648 </entry>
649 </row>
651 <row>
652 <entry><methodname>setCommentFeedLinks()</methodname></entry>
654 <entry>
655 Same as <methodname>setCommentFeedLink()</methodname> except it
656 accepts an array of arrays, where each subarray contains the
657 expected parameters of <methodname>setCommentFeedLink()</methodname>.
658 </entry>
659 </row>
661 <row>
662 <entry><methodname>setEncoding()</methodname></entry>
664 <entry>
665 Sets the encoding of entry text. This will default to UTF-8 which
666 is the preferred encoding.
667 </entry>
668 </row>
669 </tbody>
670 </tgroup>
671 </table>
673 <note>
674 <para>
675 In addition to these setters, there are also matching getters to retrieve data from
676 from the Entry data container.
677 </para>
678 </note>
679 </sect2>
680 </sect1>