fix dead link (RT#96342)

[catagits/Catalyst-Manual.git] / lib / Catalyst / Manual / Intro.pod

diff --git a/lib/Catalyst/Manual/Intro.pod b/lib/Catalyst/Manual/Intro.pod
index 407bd6c..0139fef 100644 (file)
--- a/lib/Catalyst/Manual/Intro.pod
+++ b/lib/Catalyst/Manual/Intro.pod
@@ -16,7 +16,7 @@ with Catalyst, see L<Catalyst::Manual::Tutorial>.
 Catalyst is an elegant web application framework, extremely flexible
 yet extremely simple. It's similar to Ruby on Rails, Spring (Java), and
 L<Maypole|Maypole>, upon which it was originally based. Its most
-important design philosphy is to provide easy access to all the tools
+important design philosophy is to provide easy access to all the tools
 you need to develop web applications, with few restrictions on how you
 need to use these tools. However, this does mean that it is always
 possible to do things in a different way. Other web frameworks are
@@ -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
@@ -469,7 +458,7 @@ Using plugins from a Model (for example L<Catalyst::Plugin::Cache>).
 From a style perspective it's usually considered bad form to make your
 model "too smart" about things - it should worry about business logic
 and leave the integration details to the controllers. If, however, you
-find that it does not make sense at all to use an auxillary controller
+find that it does not make sense at all to use an auxiliary controller
 around the model, and the model's need to access C<$c> cannot be
 sidestepped, there exists a power tool called L</ACCEPT_CONTEXT>.
 
@@ -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,11 +859,11 @@ 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
+shorthand for C<:Path('/methodname')>.  C<:Local> is shorthand for
 C<:Path('methodname')>, which takes the controller namespace as described
 above.
 
@@ -883,7 +872,7 @@ applications (e.g. before Catalyst 5.7).  The use cases where C<Global>
 used to make sense are now largely replaced by the C<Chained> dispatch
 type, or by empty C<Path> declarations on an controller action.  C<Global>
 is still included in Catalyst for backwards compatibility, although
-legitimate use-cases for it may still exist (but nobody can.
+legitimate use-cases for it may still exist.
 
 =item * Changing handler behaviour: eating arguments (C<:Args>)
 
@@ -1374,7 +1363,7 @@ that can be extended as you develop your project. To write your own
 comprehensive test scripts, L<Test::WWW::Mechanize::Catalyst> is an
 invaluable tool.
 
-For more testing ideas, see L<Catalyst::Manual::Tutorial::Testing>.
+For more testing ideas, see L<Catalyst::Manual::Tutorial::08_Testing>.
 
 Have fun!