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=ea6344d6f3bf292977720b883b675e4780242d63;hp=3a3b92d0b6b0ea005e2623086c356ad3907be9cd;hb=ca7528dfa8625d0ed6688f2bb93372ab3d958881;hpb=9d49ae044039a193c6fd87acd4a17c731b1a2e16

diff --git a/lib/Catalyst/Manual/Intro.pod b/lib/Catalyst/Manual/Intro.pod
index 3a3b92d..ea6344d 100644
--- a/lib/Catalyst/Manual/Intro.pod
+++ b/lib/Catalyst/Manual/Intro.pod
@@ -14,17 +14,17 @@ with Catalyst, see L<Catalyst::Manual::Tutorial>.
 =head2 What is Catalyst?
 
 Catalyst is an elegant web application framework, extremely flexible
-yet extremely simple. It's similar to Ruby on Rails, Spring (Java),
-and L<Maypole>, upon which it was originally based. Its most important
-design philosphy 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 B<initially>
-simpler to use, but achieve this by locking the programmer into a
-single set of tools. Catalyst's emphasis on flexibility means that you
-have to think more to use it. We view this as a feature.  For example,
-this leads to Catalyst being more suited to system integration tasks
-than other web frameworks.
+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
+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
+I<initially> simpler to use, but achieve this by locking the programmer
+into a single set of tools. Catalyst's emphasis on flexibility means
+that you have to think more to use it. We view this as a feature.  For
+example, this leads to Catalyst being more suited to system integration
+tasks than other web frameworks.
 
 =head3 MVC
 
@@ -104,6 +104,16 @@ example:
 
 Now http://localhost:3000/hello prints "Hello World!".
 
+Note that actions with the C< :Local > attribute are equivalent to
+using a C<:Path('/action_name') > attribute (note the leading slash).
+So our action could be equivalently:
+
+    sub hello : Path('/hello') {
+        my ( $self, $context ) = @_;
+        $context->response->body('Hello World!');
+    }
+
+
 =item * B<Support for CGI, mod_perl, Apache::Request, FastCGI>
 
 Use L<Catalyst::Engine::Apache> or L<Catalyst::Engine::CGI>. Other
@@ -216,14 +226,15 @@ means that this decision is entirely up to you, the programmer;
 Catalyst doesn't enforce anything. See L<Catalyst::Manual::About> for
 a general discussion of these issues.
 
-All components must inherit from L<Catalyst::Base>, which provides a
-simple class structure and some common class methods like C<config> and
-C<new> (constructor).
+Model, View and Controller components must inherit from L<Catalyst::Model>,
+L<Catalyst::View> and L<Catalyst::Controller>, respectively. These, in turn, inherit
+from L<Catalyst::Component> which provides a simple class structure and some
+common class methods like C<config> and C<new> (constructor).
 
     package MyApp::Controller::Catalog;
 
     use strict;
-    use base 'Catalyst::Base';
+    use base 'Catalyst::Controller';
 
     __PACKAGE__->config( foo => 'bar' );
 
@@ -336,9 +347,9 @@ Now we can create a DBIC::Schema model for this database.
 
     script/myapp_create.pl model MyModel DBIC::Schema MySchema create=static 'dbi:SQLite:/tmp/myapp.db'
 
-L<DBIx::Class::Schema::Loader> automatically loads table layouts and
-relationships, and converts them into a static schema definition C<MySchema>,
-which you can edit later.
+L<DBIx::Class::Schema::Loader> can automaticall load table layouts and
+relationships, and convert them into a static schema definition
+C<MySchema>, which you can edit later.
 
 Use the stash to pass data to your templates.
 
@@ -549,9 +560,10 @@ configure your application, load plugins, and extend Catalyst.
     package MyApp;
 
     use strict;
-    use Catalyst qw/-Debug/; # Add other plugins here, e.g.
-                             # for session support
-
+    use parent qw/Catalyst/;
+    __PACKAGE__->setup(qw/-Debug ConfigLoader Static::Simple/);
+    # note you can still use use Catalyst qw/@plugins/ instead of the
+    # above two lines
     MyApp->config(
         name => 'My Application',
 
@@ -695,9 +707,10 @@ this:
     # Sets the actions in this controller to be registered with no prefix
     # so they function identically to actions created in MyApp.pm
     __PACKAGE__->config->{namespace} = '';
-    sub default : Private {
+    sub default : Path  {
         my ( $self, $context ) = @_;
-        $context->response->body('Catalyst rocks!');
+        $context->response->status(404);
+        $context->response->body('404 not found');
     }
     1;
 
@@ -796,6 +809,11 @@ Catalyst ("MyApp::Controller" in the above example), replaces "::" with
 explanation of the pre-defined meaning of Catalyst component class
 names.
 
+Note that actions with the C< :Local > attribute are equivalent to the
+<:Path('action_name') > so sub foo : Local { } is equivalent to -
+
+    sub foo : Path('foo') { }
+
 =item * B<Chained>
 
 Catalyst also provides a method to build and dispatch chains of actions,
@@ -866,26 +884,24 @@ call these built-in private actions in your application class:
 
 =over 4
 
-=item * B<default : Private>
+=item * B<default : Path>
 
 Called when no other action matches. Could be used, for example, for
 displaying a generic frontpage for the main app, or an error page for
-individual controllers.
+individual controllers. B<Note>: in older Catalyst applications you
+will see C<default : Private> which is roughly speaking equivalent.
 
-If C<default> isn't acting how you would expect, look at using a
-L</Literal> C<Path> action (with an empty path string). The difference
-is that C<Path> takes arguments relative from the namespace and
-C<default> I<always> takes arguments relative from the root, regardless
-of what controller it's in. Indeed, this is now the recommended way of
-handling default situations; the C<default> private controller should
-be considered deprecated.
 
-=item * B<index : Private>
+=item * B<index : Path : Args (0) >
 
-C<index> is much like C<default> except that it takes no arguments
-and it is weighted slightly higher in the matching process. It is
-useful as a static entry point to a controller, e.g. to have a static
-welcome page. Note that it's also weighted higher than Path.
+C<index> is much like C<default> except that it takes no arguments and
+it is weighted slightly higher in the matching process. It is useful
+as a static entry point to a controller, e.g. to have a static welcome
+page. Note that it's also weighted higher than Path.  Actually the sub
+name C<index> can be called anything you want.  The sub attributes are
+what determines the behaviour of the action.  B<Note>: in older
+Catalyst applications, you will see C<index : Private> used, which is
+roughly speaking equivalent.
 
 =item * B<begin : Private>
 
@@ -902,7 +918,7 @@ Called at the end of a request, after all matching actions are called.
 
     Package MyApp::Controller::Foo;
     sub begin : Private { }
-    sub default : Private { }
+    sub default : Path  { }
     sub auto : Private { }
 
 You can define built-in private actions within your controllers as