X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=catagits%2FCatalyst-Manual.git;a=blobdiff_plain;f=lib%2FCatalyst%2FManual%2FCookbook.pod;h=96be5315fb46aff90e56859c2069705e418c1d41;hp=bb565356d38a8a91e6741667ae139ff16f8c3ba1;hb=01b62b15107b5d8bb4e1eb173ab8629f2ea647e9;hpb=e541538422e839971d0c91c47ea19029de01cfa5

diff --git a/lib/Catalyst/Manual/Cookbook.pod b/lib/Catalyst/Manual/Cookbook.pod
index bb56535..96be531 100644
--- a/lib/Catalyst/Manual/Cookbook.pod
+++ b/lib/Catalyst/Manual/Cookbook.pod
@@ -572,7 +572,7 @@ root of your app (but not in any other controller).
 
 =head1 Models
 
-Models are where application data belongs.  Catalyst is exteremely
+Models are where application data belongs.  Catalyst is extremely
 flexible with the kind of models that it can use.  The recipes here
 are just the start.
 
@@ -589,7 +589,7 @@ write a simple component in Catalyst that slurps in an outside Model:
 
     __PACKAGE__->config(
         schema_class => 'Some::DBIC::Schema',
-        connect_info => ['dbi:SQLite:foo.db', '', '', {AutoCommit=>1}];
+        connect_info => ['dbi:SQLite:foo.db', '', '', {AutoCommit=>1}],
     );
 
     1;
@@ -961,47 +961,13 @@ L<http://search.cpan.org/perldoc?Template>
 =head2 Adding RSS feeds
 
 Adding RSS feeds to your Catalyst applications is simple. We'll see two
-different aproaches here, but the basic premise is that you forward to
+different approaches here, but the basic premise is that you forward to
 the normal view action first to get the objects, then handle the output
 differently.
 
-=head3 Using TT templates
-
-This is the aproach used in Agave (L<http://dev.rawmode.org/>).
-
-    sub rss : Local {
-        my ($self,$c) = @_;
-        $c->forward('view');
-        $c->stash->{template}='rss.tt';
-    }
-
-Then you need a template. Here's the one from Agave:
-
-    <?xml version="1.0" encoding="UTF-8"?>
-    <rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
-      <channel>
-	<title>[ [% blog.name || c.config.name || "Agave" %] ] RSS Feed</title>
-        <link>[% base %]</link>
-        <description>Recent posts</description>
-        <language>en-us</language>
-        <ttl>40</ttl>
-     [% WHILE (post = posts.next) %]
-      <item>
-        <title>[% post.title %]</title>
-        <description>[% post.formatted_teaser|html%]</description>
-        <pubDate>[% post.pub_date %]</pubDate>
-        <guid>[% post.full_uri %]</guid>
-        <link>[% post.full_uri %]</link>
-        <dc:creator>[% post.author.screenname %]</dc:creator>
-      </item>
-    [% END %]
-      </channel>
-    </rss>
-
 =head3 Using XML::Feed
 
-A more robust solution is to use L<XML::Feed>, as was done in the Catalyst
-Advent Calendar. Assuming we have a C<view> action that populates
+Assuming we have a C<view> action that populates
 'entries' with some DBIx::Class iterator, the code would look something
 like this:
 
@@ -1025,10 +991,10 @@ like this:
         $c->res->body( $feed->as_xml );
    }
 
-A little more code in the controller, but with this approach you're
+With this approach you're
 pretty sure to get something that validates.
 
-Note that for both of the above aproaches, you'll need to set the
+Note that for both of the above approaches, you'll need to set the
 content type like this:
 
     $c->res->content_type('application/rss+xml');
@@ -1369,7 +1335,7 @@ even though there are two different methods of looking up a track.
 
 This technique can be expanded as needed to fulfil your requirements - for example,
 if you inherit the first action of a chain from a base class, then mixing in a
-different base class can be used to duplicate an entire URL hieratchy at a different
+different base class can be used to duplicate an entire URL hierarchy at a different
 point within your application.
 
 =head2 Component-based Subrequests
@@ -1565,7 +1531,7 @@ the same Apache instance because the namespaces will collide.
 
 =head4 Cannot run different versions of libraries.
 
-If you have two differnet applications which run on the same machine,
+If you have two different applications which run on the same machine,
 which need two different versions of a library then the only way to do
 this is to have per-vhost perl interpreters (with different library paths).
 This is entirely possible, but nullifies all the memory sharing benefits that