X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=catagits%2FCatalyst-Manual.git;a=blobdiff_plain;f=lib%2FCatalyst%2FManual%2FTutorial%2FBasicCRUD.pod;h=57e94193035533c0874fc1f2060e063503977b37;hp=3d2af6a4e02b77d3d22e2604a386f92f22695efc;hb=a46b474eb241c3eac09ac0cd8af400a864de3ee5;hpb=72609296f6f6f655484b1700eebaf348af82bdde diff --git a/lib/Catalyst/Manual/Tutorial/BasicCRUD.pod b/lib/Catalyst/Manual/Tutorial/BasicCRUD.pod index 3d2af6a..57e9419 100644 --- a/lib/Catalyst/Manual/Tutorial/BasicCRUD.pod +++ b/lib/Catalyst/Manual/Tutorial/BasicCRUD.pod @@ -119,14 +119,6 @@ Edit C and enter the following method: # Assign the Book object to the stash for display in the view $c->stash->{book} = $book; - # This is a hack to disable XSUB processing in Data::Dumper - # (it's used in the view). This is a work-around for a bug in - # the interaction of some versions or Perl, Data::Dumper & DBIC. - # You won't need this if you aren't using Data::Dumper (or if - # you are running DBIC 0.06001 or greater), but adding it doesn't - # hurt anything either. - $Data::Dumper::Useperl = 1; - # Set the TT template to use $c->stash->{template} = 'books/create_done.tt2'; } @@ -961,7 +953,7 @@ This will modify the C table to include the two new fields and populate those fields with the current time. -=head2 Update DBIC to Automatically Handle the Datetime Columns +=head2 Update DBIx::Class to Automatically Handle the Datetime Columns Next, we should re-run the DBIC helper to update the Result Classes with the new fields: @@ -975,7 +967,7 @@ with the new fields: exists "/root/dev/MyApp/script/../lib/MyApp/Model/DB.pm" Notice that we modified our use of the helper slightly: we told -it to include the L +it to include the L in the C line of the Result Classes. If you open C in your editor you @@ -999,10 +991,11 @@ B the C<1;> on the last line): { data_type => 'datetime', set_on_create => 1, set_on_update => 1 }, ); -This will override the definition for these fields that Schema::Loader -placed at the top of the file. The C and -C options will cause DBIC to automatically update the -timestamps in these columns whenever a row is created or modified. +This will override the definition for these fields that Schema::Loader +placed at the top of the file. The C and +C options will cause DBIx::Class to automatically +update the timestamps in these columns whenever a row is created or +modified. To test this out, restart the development server using the C option: @@ -1047,7 +1040,7 @@ controller code. To illustrate the concept with a fairly simple example, let's create a method that returns books added in the last 10 minutes. Start by -making a directory where DBIC will look for our ResultSet Class: +making a directory where DBIx::Class will look for our ResultSet Class: mkdir lib/MyApp/Schema/ResultSet @@ -1123,20 +1116,20 @@ try a higher or lower value. =head2 Chaining ResultSets -One of the most helpful and powerful features in DBIC is that it allows -you to "chain together" a series of queries (note that this has nothing -to do with the "Chained Dispatch" for Catalyst that we were discussing -above). Because each ResultSet returns another ResultSet, you can take -an initial query and immediately feed that into a second query (and so -on for as many queries you need). Note that no matter how many -ResultSets you chain together, the database itself will not be hit until -you use a method that attempts to access the data. And, because this -technique carries over to the ResultSet Class feature we implemented in -the previous section for our "canned search", we can combine the two -capabilities. For example, let's add an action to our C -controller that lists books that are both recent I have "TCP" in -the title. Open up C and add the -following method: +One of the most helpful and powerful features in DBIx::Class is that +it allows you to "chain together" a series of queries (note that this +has nothing to do with the "Chained Dispatch" for Catalyst that we +were discussing above). Because each ResultSet returns another +ResultSet, you can take an initial query and immediately feed that +into a second query (and so on for as many queries you need). Note +that no matter how many ResultSets you chain together, the database +itself will not be hit until you use a method that attempts to access +the data. And, because this technique carries over to the ResultSet +Class feature we implemented in the previous section for our "canned +search", we can combine the two capabilities. For example, let's add +an action to our C controller that lists books that are both +recent I have "TCP" in the title. Open up +C and add the following method: =head2 list_recent_tcp @@ -1241,16 +1234,16 @@ more flexible at the same time. =head2 Adding Methods to Result Classes -In the previous two sections we saw a good example of how we could use -DBIC ResultSet Classes to clean up our code for an entire query (for -example, our "canned searches" that filtered the entire query). We -can do a similar improvement when working with individual rows as -well. Whereas the ResultSet construct is used in DBIC to correspond -to an entire query, the Result Class construct is used to represent a -row. Therefore, we can add row-specific "helper methods" to our Result -Classes stored in C. For example, open -C and add the following method -(as always, it must be above the closing "C<1;>"): +In the previous two sections we saw a good example of how we could use +DBIx::Class ResultSet Classes to clean up our code for an entire query +(for example, our "canned searches" that filtered the entire query). +We can do a similar improvement when working with individual rows as +well. Whereas the ResultSet construct is used in DBIC to correspond +to an entire query, the Result Class construct is used to represent a +row. Therefore, we can add row-specific "helper methods" to our Result +Classes stored in C. For example, open +C and add the following method (as +always, it must be above the closing "C<1;>"): # # Helper methods