From: Jesse Sheidlower Date: Sun, 17 Apr 2005 01:18:02 +0000 (+0000) Subject: Fixed: More minor typos X-Git-Tag: 5.7099_04~1487 X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=07e73f821bce2ecf2846ddb2e1b120513d23cb18;p=catagits%2FCatalyst-Runtime.git Fixed: More minor typos --- diff --git a/lib/Catalyst/Manual/Internals.pod b/lib/Catalyst/Manual/Internals.pod index ae8e9f9..dcebdc4 100644 --- a/lib/Catalyst/Manual/Internals.pod +++ b/lib/Catalyst/Manual/Internals.pod @@ -4,12 +4,13 @@ Catalyst::Manual::Internals - Catalyst Internals =head1 DESCRIPTION -This document provides an overview of the internals of Catalyst. As Catalyst -is still developing rapidly details may become out of date. +This document provides an overview of the internals of +Catalyst. As Catalyst is still developing rapidly, details +may become out of date: please treat this as a guide, and +look at the source for the last word. The coverage is split into initialization and request lifecycle. - =head2 Initialization Catalyst initializes itself in two stages (I may be wrong in some of @@ -19,18 +20,19 @@ the details here - AF): =item 1 -When the Catalyst module is imported in the main application module it -evaluates any options (C<-Debug>, C<-Engine=XXX>) and loads any specified -plugins, making application module inherit from the plugin classes. It also -sets up a default log object and ensures that the application module inherits -from C and from the selected specialized Engine module. +When the Catalyst module is imported in the main application +module it evaluates any options (C<-Debug>, C<-Engine=XXX>) +and loads any specified plugins, making the application module +inherit from the plugin classes. It also sets up a default log +object and ensures that the application module inherits from +C and from the selected specialized Engine module. =item 2 When the application module makes the first call to C<< __PACKAGE__->action() >> -(implemented in C) Catalyst automatically loads all -components it finds in the C<$class\::Controller>, C<$class\::C>, -C<$class\::Model>, C<$class\::M>, C<$class\::View> and C<$class\::V> +(implemented in C), Catalyst automatically loads all +components it finds in the C<$class::Controller>, C<$class::C>, +C<$class::Model>, C<$class::M>, C<$class::View> and C<$class::V> namespaces (using C). A table of actions is built up and added to on subsequent calls to C. @@ -40,7 +42,7 @@ and added to on subsequent calls to C. =head2 Request Lifecycle For each request Catalyst builds a I object, which includes -information about the request, and searches the action table for matching +information about the request, and then searches the action table for matching actions. The handling of a request can be divided into three stages: preparation of the diff --git a/lib/Catalyst/Manual/SuccessStories.pod b/lib/Catalyst/Manual/SuccessStories.pod index a327ea7..a15385a 100644 --- a/lib/Catalyst/Manual/SuccessStories.pod +++ b/lib/Catalyst/Manual/SuccessStories.pod @@ -50,7 +50,7 @@ or so of public beta testing, I shifted the entire site to the new system, e-mailed Slashdot, and waited for the onslaught. When it hit Slashdot, things held up very nicely. (Some early -error pages, embarrassedly pointed out by a Slashdot poster, +error pages, embarrassingly pointed out by a Slashdot poster, were in fact caused by a lack of available MySQL connections, for which misconfiguration the DB admin was harshly criticized, rather than from any app-specific failings.) In diff --git a/lib/Catalyst/Manual/Tutorial.pod b/lib/Catalyst/Manual/Tutorial.pod index 3fc66fe..af64d7f 100644 --- a/lib/Catalyst/Manual/Tutorial.pod +++ b/lib/Catalyst/Manual/Tutorial.pod @@ -59,7 +59,7 @@ files. =head2 Testing out the sample application You can test out your new application by running the server script that -catalyst provides: +Catalyst provides: $ cd My-App $ script/server.pl @@ -69,7 +69,7 @@ catalyst provides: .=----------------------+----------------------+---------------=. | Private | Class | Code | |=----------------------+----------------------+---------------=| - | /default | MyApp | CODE(0x86f08ac | + | /default | MyApp | CODE(0x86f08ac)| '=----------------------+----------------------+---------------=' "My::App" defined "!default" as "CODE(0x83fd570)" [...] [catalyst] [info] My::App powered by Catalyst 5.00 @@ -186,7 +186,7 @@ the application module). The call to C sets up configuration data for the application. The C and C items are the minimum required, and specify the name of the application and the path to the root directory where -documents, images and templates can be found. +documents, images, and templates can be found. Catalyst associates I with URLs and on receiving a request dispatches to the action that matches to request URL. The call to @@ -196,11 +196,10 @@ with the same message "Congratulations, My::App is on Catalyst!". As you see, the default action is defined as a Private action. Most private actions are not directly available from a web url. This -also includes the built-in actions, 'default','begin','end' and +also includes the built-in actions, 'default','begin','end', and 'auto', although they will be called as part of some chains. The rest can only be reached by using C. - The call to the C method also triggers the second stage of Catalyst's initialization process. In this phase Catalyst searches for any component modules, locating and registering any actions it @@ -230,7 +229,7 @@ You can start extending the application by adding new actions: } -TODO: explain briefly about plugins, actions and components +TODO: explain briefly about plugins, actions, and components regex actions passed subexpression matches in $c->req->snippets (array ref). @@ -244,7 +243,7 @@ Catalyst works well with Template Toolkit. If you are unfamiliar with Template Toolkit then I suggest you look at L, install C