X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=catagits%2FCatalyst-Manual.git;a=blobdiff_plain;f=lib%2FCatalyst%2FManual%2FIntro.pod;h=7a98dfd1b6a1c8d24ff30c19870fba68c2ff315a;hp=741a79fb04ce393065d2ae36a86746dd690514c3;hb=834c324a7ec6264314f49171a9bd63aa555d3bd1;hpb=7c8f8c03513851be71bef7cf67c6de202a7c4d2c

diff --git a/lib/Catalyst/Manual/Intro.pod b/lib/Catalyst/Manual/Intro.pod
index 741a79f..7a98dfd 100644
--- a/lib/Catalyst/Manual/Intro.pod
+++ b/lib/Catalyst/Manual/Intro.pod
@@ -122,14 +122,14 @@ separately - which will turn the built server into a fully fledged production
 ready server (although you'll probably want to run it behind a front end proxy
 if you end up using it).
 
-=back
-
 =item * PSGI Support
 
 Starting with Catalyst version 5.9 Catalyst ships with L<PSGI> integration
 for even more powerful and flexible testing and deployment options.  See
 L<Catalyst::PSGI> for details.
 
+=back
+
 =head3 Simplicity
 
 The best part is that Catalyst implements all this flexibility in a very
@@ -266,23 +266,12 @@ short alias for each one.
 
 =item * B<MyApp/Model/>
 
-=item * B<MyApp/M/>
-
 =item * B<MyApp/View/>
 
-=item * B<MyApp/V/>
-
 =item * B<MyApp/Controller/>
 
-=item * B<MyApp/C/>
-
 =back
 
-In older versions of Catalyst, the recommended practice (and the one
-automatically created by helper scripts) was to name the directories
-C<M/>, C<V/>, and C<C/>. Though these still work, they are deprecated
-and we now recommend the use of the full names.
-
 =head4 Views
 
 To show how to define views, we'll use an already-existing base class for the
@@ -482,9 +471,9 @@ application.
 
     use base qw/Catalyst::Controller/;
 
-    sub login : Path("login") { }
+    sub sign_in : Path("sign-in") { }
     sub new_password : Path("new-password") { }
-    sub logout : Path("logout") { }
+    sub sign_out : Path("sign-out") { }
 
     package MyApp::Controller::Catalog;
 
@@ -540,7 +529,7 @@ Generally it's a bad idea to expose the context object (C<$c>) in your
 model or view code.  Instead you use the C<ACCEPT_CONTEXT> subroutine
 to grab the bits of the context object that you need, and provide
 accessors to them in the model.  This ensures that C<$c> is only in
-scope where it is neaded which reduces maintenance and debugging
+scope where it is needed which reduces maintenance and debugging
 headaches.  So, if for example you needed two
 L<Catalyst::Model::DBIC::Schema> models in the same Catalyst model
 code, you might do something like this:
@@ -790,7 +779,7 @@ of Catalyst component class names.
 
 =item * B<Overriding the namespace>
 
-Note that I<< __PACKAGE__->config->(namespace => ... ) >> can be used to override the
+Note that C<< __PACKAGE__->config->(namespace => ... ) >> can be used to override the
 current namespace when matching.  So:
 
     package MyApp::Controller::Example;
@@ -870,8 +859,8 @@ subroutine name together determine the path.
 
 1;
 
-Matches http://localhost:3000/foo - that is, the action is mapped
-directly to the controller namespace, ignoring the function name.
+Matches http://localhost:3000/bar - that is, the action is mapped
+directly to the method name, ignoring the controller namespace.
 
 C<:Global> always matches from the application root: it is simply
 shorthandfor C<:Path('/methodname')>.  C<:Local> is shorthand for