X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FReaction%2FManual%2FTutorial.pod;h=ca0fdc3059d4962dce935a00be53250ad3a720f6;hb=4b70129e4e977a51616faaaeefd61a39367861f0;hp=1753577ea640d80db58136e458f595808f03f58d;hpb=f9b32c83550e273bec97c9be5b63079addd4846b;p=catagits%2FReaction.git

diff --git a/lib/Reaction/Manual/Tutorial.pod b/lib/Reaction/Manual/Tutorial.pod
index 1753577..ca0fdc3 100644
--- a/lib/Reaction/Manual/Tutorial.pod
+++ b/lib/Reaction/Manual/Tutorial.pod
@@ -17,6 +17,12 @@ script as we would for any other Catalyst application:
 
 There is nothing to change in the application class file.
 
+As you work through this tutorial you'll be creating several new files in
+various directories. You can save some time by creating the directories now,
+like this:
+
+  mkdir -p share/skin/myapp/layout lib/MyApp/View/Site/Widget lib/MyApp/Schema lib/MyApp/InterfaceModel
+
 =head1 THE VIEW
 
 Since we are not just rendering templates with Reaction, but layouts and widgets,
@@ -25,7 +31,7 @@ a simple TT view won't suffice. We need to create our own C<lib/MyApp/View/Site.
   package MyApp::View::Site;
   use Reaction::Class;
   
-  use namespace::clean -except => 'meta';
+  use namespace::autoclean;
   
   extends 'Reaction::UI::View::TT';
   
@@ -37,8 +43,7 @@ The C<use Reaction::Class> line will import L<Moose>, L<strict> and L<warnings>
 our file and might perform some Reaction specific setups.
 
 We make sure that we don't provide imported functions as methods at runtime by using
-L<namespace::clean>. But we need to C<-except> the C<meta> method that was exported
-by Moose.
+L<namespace::autoclean>.
 
 In its simplest version, our view just needs to do a C<extends 'Reaction::UI::View::TT'>
 to make a new subclass of it.
@@ -59,7 +64,7 @@ the root namespace for our application. For this purpose, it should look like th
   use aliased 'Reaction::UI::ViewPort';
   use aliased 'Reaction::UI::ViewPort::SiteLayout';
   
-  use namespace::clean -except => 'meta';
+  use namespace::autoclean;
   
   __PACKAGE__->config(
       view_name       => 'Site',
@@ -72,6 +77,11 @@ the root namespace for our application. For this purpose, it should look like th
       $self->push_viewport(SiteLayout,
           title           => 'MyApp Test Title',
           static_base_uri => join('', $ctx->uri_for('/static')),
+          meta_info       => {
+              http_header   => {
+                  'Content-Type' => 'text/html;charset=utf-8',
+              },
+          },
       );
   }
   
@@ -82,8 +92,8 @@ the root namespace for our application. For this purpose, it should look like th
   
   1;
 
-The effects of L<strict>, L<warnings>, L<parent>, L<aliased> and L<namespace::clean> should
-be clear by now. Let's take a look at the configuration.
+The effects of L<strict>, L<warnings>, L<parent>, L<aliased> and L<namespace::autoclean>
+should be clear by now. Let's take a look at the configuration.
 
 The C<view_name> determines which view to use. We set it to C<Site>, which is our only view
 by now. Be careful to set C<view_name> and not C<view>, which would fail telling you it 
@@ -186,7 +196,7 @@ where the deeper parts of the stack will be included, in the case of our C<root>
 would be the C<Reaction::UI::ViewPort> with the C<root> layout.
 
 If we wanted to override a specific fragment, we could do just that. And inside that fragment
-we could call C<[% next_call %]> to include the layout fragment from the extended layout.
+we could call C<[% call_next %]> to include the layout fragment from the extended layout.
 
 The layout representing the root action is called C<share/skin/myapp/layout/root.tt>:
 
@@ -214,7 +224,7 @@ widget at C<lib/MyApp/View/Site/Widget/Root.pm>:
   package MyApp::View::Site::Widget::Root;
   use Reaction::UI::WidgetClass;
   
-  use namespace::clean -except => 'meta';
+  use namespace::autoclean;
   
   __PACKAGE__->meta->make_immutable;
   
@@ -239,7 +249,7 @@ takes this one step further by introducing so called interface models. The inter
 defines the layer between your application and your domain model (in this case, the L<DBIx::Class>
 schema).
 
-The first thing we will need is a schema class:
+The first thing we will need is a schema class in C<lib/MyApp/Schema.pm>:
 
   package MyApp::Schema;
   use strict;
@@ -267,14 +277,14 @@ called C<example.sqlite>:
   $
 
 The result class for this table combines the usual style of L<DBIx::Class> with L<Moose> meta
-data additions:
+data additions in C<lib/MyApp/Schema/Foo.pm>:
 
   package MyApp::Schema::Foo;
   use Moose;
   use MooseX::Types::Moose  qw( Int );
   use Reaction::Types::Core qw( NonEmptySimpleStr );
   
-  use namespace::clean -except => 'meta';
+  use namespace::autoclean;
   
   extends 'DBIx::Class';
   
@@ -325,7 +335,8 @@ inspect many-to-many relations later on.
 
 The interface model should be separated from the application and the schema, since it
 will tie both together. In this case, we will use a reflector to set up the usual interface
-model actions for our schema (C<Create>, C<Update>, C<Delete>, C<DeleteAll>):
+model actions for our schema (C<Create>, C<Update>, C<Delete>, C<DeleteAll>) in
+C<lib/MyApp/InterfaceModel/DBIC.pm>:
 
   package MyApp::InterfaceModel::DBIC;
   
@@ -335,7 +346,7 @@ model actions for our schema (C<Create>, C<Update>, C<Delete>, C<DeleteAll>):
   use Reaction::Class;
   use Reaction::InterfaceModel::Reflector::DBIC;
   
-  use namespace::clean -except => 'meta';
+  use namespace::autoclean;
   
   my $reflector = Reaction::InterfaceModel::Reflector::DBIC->new;
   
@@ -361,7 +372,7 @@ this we create a simple catalyst model in C<lib/MyApp/Model/DBIC.pm>:
   package MyApp::Model::DBIC;
   use Reaction::Class;
   
-  use namespace::clean -except => 'meta';
+  use namespace::autoclean;
   
   extends 'Catalyst::Model::Reaction::InterfaceModel::DBIC';
   
@@ -376,13 +387,18 @@ this we create a simple catalyst model in C<lib/MyApp/Model/DBIC.pm>:
 
 This model L<extends|Moose> the L<Catalyst::Model::Reaction::InterfaceModel::DBIC> base class
 shipped with Reaction. It's configuration must contain the C<im_class> naming our interface
-model and the C<db_dsn>. Of course, since this is Catalyst, this can also easily be specified 
+model and the C<db_dsn>. If you're using a different kind of database then you
+may neeb to add config for C<db_user>, C<db_password>, and C<db_params>.
+All these get passed to the schema's connect() method.
+
+Of course, since this is Catalyst, all this can also easily be specified 
 via your application config file under the C<Model::DBIC> key.
 
 =head1 BUILDING A SIMPLE CRUD CONTROLLER
 
 Now, since we have defined our interface model as well as our domain model including meta
-data, it isn't very hard (at least not for us) to build a basic (but extendable) CRUD controller:
+data, it isn't very hard (at least not for us) to build a basic (but extendable)
+CRUD controller in C<lib/MyApp/Controller/Foo.pm>:
 
   package MyApp::Controller::Foo;
   use strict;
@@ -391,7 +407,7 @@ data, it isn't very hard (at least not for us) to build a basic (but extendable)
   use parent 'Reaction::UI::Controller::Collection::CRUD';
   use Reaction::Class;
   
-  use namespace::clean -except => 'meta';
+  use namespace::autoclean;
   
   __PACKAGE__->config(
       model_name      => 'DBIC',
@@ -411,7 +427,7 @@ As you can see, for the simplest case we don't need any code; we simply configur
 
 The C<model_name> is the name of our interface model sans the C<MyApp::Model::> prefix. This means
 this entry points to C<MyApp::Model::DBIC> in this case. The C<collection_name> is the name of
-the collection in the specified interface model. For us, this would be C<Foo>, like the result
+the collection in the specified interface model. For us, this would be C<Foo>, to match the result
 class we created above and want to manage.
 
 The C<actions> part of the configuration is not Reaction, but rather Catalyst specific. This