use double bracketed formatting codes so < and > don't need to be escaped
[catagits/Catalyst-Manual.git] / lib / Catalyst / Manual / Cookbook.pod
index 5e279f0..a550208 100644 (file)
@@ -1,3 +1,5 @@
+=encoding utf8
+
 =head1 NAME
 
 Catalyst::Manual::Cookbook - Cooking with Catalyst
@@ -68,7 +70,7 @@ Normally you enable the debugging info by adding the C<-Debug> flag to
 your C<use Catalyst> statement . However, you can also enable it using
 environment variable, so you can (for example) get debug info without
 modifying your application scripts. Just set C<CATALYST_DEBUG> or
-C<E<lt>MYAPPE<gt>_DEBUG> to a true value.
+C<< <MYAPP>_DEBUG >> to a true value.
 
 =head2 Sessions
 
@@ -110,7 +112,7 @@ retrieve the user data for you.
 =head3 Using a session
 
 Once the session modules are loaded, the session is available as C<<
-$c->session >>, and can be writen to and read from as a simple hash
+$c->session >>, and can be written to and read from as a simple hash
 reference.
 
 =head3 EXAMPLE
@@ -215,6 +217,10 @@ This is equivalent to:
   # configure email sending
   __PACKAGE__->config( email => [qw/SMTP localhost/] );
 
+L<Catalyst> explains precedence of multiple sources for configuration
+values, how to access the values in your components, and many 'base'
+config variables used internally.
+
 See also L<Config::General|Config::General>.
 
 =head1 Skipping your VCS's directories
@@ -845,7 +851,7 @@ organization provided makes it much easier to standardize pages and make
 changes when they are (inevitably) needed.
 
 The template files that you will create for your application will go
-into root/src, and you don't need to worry about putting the the <html>
+into root/src, and you don't need to worry about putting the <html>
 or <head> sections; just put in the content. The WRAPPER will the rest
 of the page around your template for you.
 
@@ -1419,13 +1425,13 @@ And in the controller:
         $c->stash->{template} = 'file_upload.html';
     }
 
-C<for my $field ($c-E<gt>req->upload)> loops automatically over all file
+C<< for my $field ($c->req->upload) >> loops automatically over all file
 input fields and gets input names. After that is basic file saving code,
 just like in single file upload.
 
 Notice: C<die>ing might not be what you want to do, when an error
 occurs, but it works as an example. A better idea would be to store
-error C<$!> in $c->stash->{error} and show a custom error template
+error C<$!> in C<< $c->stash->{error} >> and show a custom error template
 displaying this message.
 
 For more information about uploads and usable methods look at
@@ -1619,7 +1625,7 @@ static content to the view, perhaps like this:
 
 This code will only forward to the view if a template has been
 previously defined by a controller and if there is not already data in
-C<$c-E<gt>res-E<gt>body>.
+C<< $c->res->body >>.
 
 Next, create a controller to handle requests for the /static path. Use
 the Helper to save time. This command will create a stub controller as
@@ -1748,7 +1754,7 @@ allows old entries to be automatically expired when they are no longer needed.
 =head3 Page Caching
 
 Another method of caching is to cache the entire HTML page.  While this is
-traditionally handled by a front-end proxy server like Squid, the Catalyst
+traditionally handled by a frontend proxy server like Squid, the Catalyst
 PageCache plugin makes it trivial to cache the entire output from
 frequently-used or slow actions.
 
@@ -1786,7 +1792,7 @@ Note that the page cache is keyed on the page URI plus all parameters, so
 requests for / and /?foo=bar will result in different cache items.  Also,
 only GET requests will be cached by the plugin.
 
-You can even get that front-end Squid proxy to help out by enabling HTTP
+You can even get that frontend Squid proxy to help out by enabling HTTP
 headers for the cached page.
 
     MyApp->config(