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=ea85c86b1a32db47d90f6d3dedbc17ded3d21cfe;hp=f689e411636752cfff6bdb80c55eb72739dc0128;hb=cacb3819a45beb62da8e38784e503e976e3ebb69;hpb=34626ececd68c62de41f1725dbcf8a25ba8c21b6 diff --git a/lib/Catalyst/Manual/Cookbook.pod b/lib/Catalyst/Manual/Cookbook.pod index f689e41..ea85c86 100644 --- a/lib/Catalyst/Manual/Cookbook.pod +++ b/lib/Catalyst/Manual/Cookbook.pod @@ -70,7 +70,7 @@ Normally you enable the debugging info by adding the C<-Debug> flag to your C 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 or -CMYAPPE_DEBUG> to a true value. +C<< _DEBUG >> to a true value. =head2 Sessions @@ -180,7 +180,7 @@ L is a method for creating flexible and readable configuration files. It's a great way to keep your Catalyst application configuration in one easy-to-understand location. -Now create C in your application home: +Now create F in your application home: name MyApp @@ -1050,7 +1050,7 @@ Note the use of quotes around the filename; this ensures that any spaces in the filename are handled by the browser. Put this right before calling C<< $c->res->body >> and your browser -will download a file named C instead of +will download a file named F instead of C. You can also use this to have the browser download content which it @@ -1505,8 +1505,8 @@ production environment. Static::Simple is a plugin that will help to serve static content for your application. By default, it will serve most types of files, excluding some standard Template Toolkit extensions, out of your B file directory. All -files are served by path, so if B is requested, then -B is found and served. +files are served by path, so if F is requested, then +F is found and served. =head3 Usage @@ -1519,12 +1519,12 @@ and already files will be served. =head3 Configuring Static content is best served from a single directory within your root -directory. Having many different directories such as C and -C requires more code to manage, because you must separately -identify each static directory--if you decide to add a C +directory. Having many different directories such as F and +F requires more code to manage, because you must separately +identify each static directory--if you decide to add a F directory, you'll need to change your code to account for it. In contrast, keeping all static directories as subdirectories of a main -C directory makes things much easier to manage. Here's an +F directory makes things much easier to manage. Here's an example of a typical root directory structure: root/ @@ -1537,7 +1537,7 @@ example of a typical root directory structure: root/static/js/code.js -All static content lives under C, with everything else being +All static content lives under F, with everything else being Template Toolkit files. =over 4 @@ -1625,11 +1625,11 @@ 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-Eres-Ebody>. +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 -C. +F. $ script/myapp_create.pl controller Static @@ -1681,7 +1681,7 @@ code in your Static controller: When using Apache, you can bypass Catalyst and any Static plugins/controllers controller by intercepting requests for the -C path at the server level. All that is required is to +F path at the server level. All that is required is to define a DocumentRoot and add a separate Location block for your static content. Here is a complete config for this application under mod_perl 1.x: @@ -1850,12 +1850,12 @@ alterations. Catalyst provides a convenient way of testing your application during development and before deployment in a real environment. -C makes it possible to run the same tests both locally +L makes it possible to run the same tests both locally (without an external daemon) and against a remote server via HTTP. =head3 Tests -Let's examine a skeleton application's C directory: +Let's examine a skeleton application's F directory: mundus:~/MyApp chansen$ ls -l t/ total 24 @@ -1865,17 +1865,17 @@ Let's examine a skeleton application's C directory: =over 4 -=item C<01app.t> +=item F<01app.t> Verifies that the application loads, compiles, and returns a successful response. -=item C<02pod.t> +=item F<02pod.t> Verifies that all POD is free from errors. Only executed if the C environment variable is true. -=item C<03podcoverage.t> +=item F<03podcoverage.t> Verifies that all methods/functions have POD coverage. Only executed if the C environment variable is true. @@ -1894,7 +1894,7 @@ The first line declares how many tests we are going to run, in this case two. The second line tests and loads our application in test mode. The fourth line verifies that our application returns a successful response. -C exports two functions, C and C. Each can +L exports two functions, C and C. Each can take three different arguments: =over 4 @@ -1904,17 +1904,17 @@ take three different arguments: request('/my/path'); request('http://www.host.com/my/path'); -=item An instance of C. +=item An instance of L. request( URI->new('http://www.host.com/my/path') ); -=item An instance of C. +=item An instance of L. request( HTTP::Request->new( GET => 'http://www.host.com/my/path') ); =back -C returns an instance of C and C returns the +C returns an instance of L and C returns the content (body) of the response. =head3 Running tests locally @@ -1945,9 +1945,9 @@ C is the absolute deployment URI of your application. In C or C it should be the host and path to the script. -=head3 C and Catalyst +=head3 L and Catalyst -Be sure to check out C. It makes it easy to +Be sure to check out L. It makes it easy to test HTML, forms and links. A short example of usage: use Test::More tests => 6;