=head1 NAME
-Catalyst::Manual::Tutorial::BasicCRUD - Catalyst Tutorial - Part 4: Basic CRUD
+Catalyst::Manual::Tutorial::BasicCRUD - Catalyst Tutorial - Chapter 4: Basic CRUD
=head1 OVERVIEW
-This is B<Part 4 of 10> for the Catalyst tutorial.
+This is B<Chapter 4 of 10> for the Catalyst tutorial.
L<Tutorial Overview|Catalyst::Manual::Tutorial>
=head1 DESCRIPTION
-This part of the tutorial builds on the fairly primitive application
-created in Part 3 to add basic support for Create, Read, Update, and
-Delete (CRUD) of C<Book> objects. Note that the 'list' function in Part
-2 already implements the Read portion of CRUD (although Read normally
-refers to reading a single object; you could implement full read
-functionality using the techniques introduced below). This section will
-focus on the Create and Delete aspects of CRUD. More advanced
-capabilities, including full Update functionality, will be addressed in
-Part 9.
-
-Although this part of the tutorial will show you how to build CRUD
-functionality yourself, another option is to use a "CRUD builder" type
-of tool to automate the process. You get less control, but it's quick
-and easy. For example, see
-L<CatalystX::ListFramework::Builder|CatalystX::ListFramework::Builder>,
-L<CatalystX::CRUD|CatalystX::CRUD>, and
+This chapter of the tutorial builds on the fairly primitive
+application created in Chapter 3 to add basic support for Create,
+Read, Update, and Delete (CRUD) of C<Book> objects. Note that the
+'list' function in Chapter 2 already implements the Read portion of
+CRUD (although Read normally refers to reading a single object; you
+could implement full read functionality using the techniques
+introduced below). This section will focus on the Create and Delete
+aspects of CRUD. More advanced capabilities, including full Update
+functionality, will be addressed in Chapter 9.
+
+Although this chapter of the tutorial will show you how to build CRUD
+functionality yourself, another option is to use a "CRUD builder" type
+of tool to automate the process. You get less control, but it's quick
+and easy. For example, see
+L<CatalystX::ListFramework::Builder|CatalystX::ListFramework::Builder>,
+L<CatalystX::CRUD|CatalystX::CRUD>, and
L<CatalystX::CRUD::YUI|CatalystX::CRUD::YUI>.
You can checkout the source code for this example from the catalyst
to the base TT capabilities. Here, the plugin allows
L<Data::Dumper|Data::Dumper> "pretty printing" of objects and
variables. Other than that, the rest of the code should be familiar
-from the examples in Part 3.
+from the examples in Chapter 3.
=head2 Try the C<url_create> Feature
=head1 CONVERT TO A CHAINED ACTION
Although the example above uses the same C<Local> action type for the
-method that we saw in the previous part of the tutorial, there is an
+method that we saw in the previous chapter of the tutorial, there is an
alternate approach that allows us to be more specific while also
paving the way for more advanced capabilities. Change the method
declaration for C<url_create> in C<lib/MyApp/Controller/Books.pm> you
As we will see shortly, a chain can consist of as many "links" as you
wish, with each part capturing some arguments and doing some work
along the way. We will continue to use the Chained action type in this
-part of the tutorial and explore slightly more advanced capabilities
+chapter of the tutorial and explore slightly more advanced capabilities
with the base method and delete feature below. But Chained dispatch
is capable of far more. For additional information, see
L<Catalyst::Manual::Intro/Action types>,
B<Note:> Having the user enter the primary key ID for the author is
obviously crude; we will address this concern with a drop-down list in
-Part 9.
+Chapter 9.
=head1 A SIMPLE DELETE FEATURE
=head2 Using C<uri_for> to Pass Query Parameters
-There are several ways to pass information across a redirect. One
-option is to use the C<flash> technique that we will see in Part 5 of
-the tutorial; however, here we will pass the information via query
-parameters on the redirect itself. Open
-C<lib/MyApp/Controller/Books.pm> and update the existing C<sub delete>
+There are several ways to pass information across a redirect. One
+option is to use the C<flash> technique that we will see in Chapter 5
+of the tutorial; however, here we will pass the information via query
+parameters on the redirect itself. Open
+C<lib/MyApp/Controller/Books.pm> and update the existing C<sub delete>
method to match the following:
=head2 delete
B<NOTE:> Another popular method for maintaining server-side
information across a redirect is to use the C<flash> technique we
-discuss in the next part of the tutorial,
+discuss in the next chapter of the tutorial,
L<Authentication|Catalyst::Manual::Tutorial::Authentication>. While
C<flash> is a "slicker" mechanism in that it's all handled by the
server and doesn't "pollute" your URLs, B<it is important to note that
of them in your applications.
-=head2 Convert to DBIC "load_namespaces"
-
-If you look back at
-L<Catalyst::Manual::Tutorial::MoreCatalystBasics/Create Static DBIC
-Schema Files> you will recall that we load our DBIC Result Classes
-(Books.pm, Authors.pm and BookAuthors.pm) with in
-C<lib/MyApp/Schema.pm> with the C<load_classes> feature. Although
-this method is perfectly valid, the DBIC community has migrated to a
-newer C<load_namespaces> technique because it more easily supports a
-variety of advanced features. Since we want to explore some of these
-features below, let's first migrate our configuration over to use
-C<load_namespaces>.
-
-If you are following along in Debian 5, you will need to upgrade your
-version of
-L<Catalyst::Model::DBIC::Schema|Catalyst::Model::DBIC::Schema> to 0.23
-or higher. To do this, we can install directly from CPAN via the
-following command:
-
- $ sudo cpan Catalyst::Model::DBIC::Schema
-
-Then make sure you are running an appropriate version:
-
- $ perl -MCatalyst::Model::DBIC::Schema -e \
- 'print "$Catalyst::Model::DBIC::Schema::VERSION\n"'
- 0.23
-
-Make sure you get version 0.23 or higher.
-
-B<Note:> Debian will automatically "do the right thing" and use the
-module we installed from CPAN and ignore the older version we picked
-up via the C<aptitude> command. If you are using a different
-environment, you will need to make sure you are using v0.23 or higher
-with the command above.
-
-While we are at it, let's install a few other modules from CPAN for
-some of the other work we will be doing below:
-
- $ cpan Time::Warp DBICx::TestDatabase \
- DBIx::Class::DynamicDefault DBIx::Class::TimeStamp
-
-Next, we need to delete the existing C<lib/MyApp/Schema.pm> so that
-the Catalyst DBIC helper will recreate it. Then we re-generate
-the model and schema information:
-
- $ rm lib/MyApp/Schema.pm
- $ script/myapp_create.pl model DB DBIC::Schema MyApp::Schema \
- create=static components=TimeStamp dbi:SQLite:myapp.db
- exists "/root/dev/MyApp/script/../lib/MyApp/Model"
- exists "/root/dev/MyApp/script/../t"
- Dumping manual schema for MyApp::Schema to directory /root/dev/MyApp/script/../lib ...
- Schema dump completed.
- exists "/root/dev/MyApp/script/../lib/MyApp/Model/DB.pm"
- $
- $ ls lib/MyApp/Schema
- Authors.pm BookAuthors.pm Books.pm Result
- $ ls lib/MyApp/Schema/Result
- Authors.pm BookAuthors.pm Books.pm
-
-Notice that we now have a duplicate set of Result Class files. With
-the newer C<load_namespaces> feature, DBIC automatically looks for
-your Result Class files in a subdirectory of the Schema directory
-called C<Result> (the files in C<lib/MyApp/Schema> were already there
-from Part 3 of the tutorial; the files in C<lib/MyApp/Schema/Result>
-are new).
-
-If you are using SQLite, you will need to manually re-enter the
-relationship configuration as we did in Part 3 of the tutorial (if you
-are using different database, the relationships might have been auto-
-generated by Schema::Loader). One option is to use the following
-command-line perl script to migrate the information across
-automatically:
-
- $ cd lib/MyApp/Schema
- $ perl -MIO::All -e 'for (@ARGV) { my $s < io($_); $s =~ s/.*\n\# You can replace.*?\n//s;
- $s =~ s/'MyApp::Schema::/'MyApp::Schema::Result::/g; my $d < io("Result/$_");
- $d =~ s/1;\n?//; "$d$s" > io("Result/$_"); }' *.pm
- $ cd ../../..
-
-If you prefer, you can do the migration by hand using "cut and paste"
-from the files in C<lib/MyApp/Schema> (or from
-L<Catalyst::Manual::Tutorial::MoreCatalystBasics/Updating the Generated DBIC Schema Files>)
-to the corresponding files in C<lib/MyApp/Schema/Result>. If you take
-this approach, be sure to add C<::Result> to the end of
-C<MyApp::Schema> in all three files (for example, in C<Books.pm>, the
-"peer class" in the C<has_many> relationship needs to be changed from
-C<MyApp::Schema::BookAuthors> to C<MyApp::Schema::BookAuthors::Result>).
-
-Now we can remove the original set of Result Class files that we no
-longer need:
-
- $ rm lib/MyApp/Schema/*.pm
- $ ls lib/MyApp/Schema
- Result
-
-Finally, test the application to be sure everything is still
-working under our new configuration. Use the
-C<script/myapp_server.pl> command to start the development server and
-point your browser to L<http://localhost:3000/books/list>. Make sure
-you see the existing list of books.
-
-
=head2 Add Datetime Columns to Our Existing Books Table
Let's add two columns to our existing C<books> table to track when
projects / catagits/Catalyst-Manual.git / blobdiff