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=16f37395d1567edc728648c1ca5bd02bea0b4aaa;hp=6b5d47ad64520beb7311553a7c3df2c6f7e858fc;hb=f4e9de4a3171fd75d04fa8e294fd9a0ae367bc18;hpb=7e4aa7c669d1a0e4e8183c6c9186a77b0079ad3d diff --git a/lib/Catalyst/Manual/Cookbook.pod b/lib/Catalyst/Manual/Cookbook.pod index 6b5d47a..16f3739 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 @@ -112,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 @@ -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 @@ -851,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 +into root/src, and you don't need to worry about putting the or sections; just put in the content. The WRAPPER will the rest of the page around your template for you. @@ -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 @@ -1425,13 +1425,13 @@ And in the controller: $c->stash->{template} = 'file_upload.html'; } -Creq->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: Cing 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 @@ -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.