Tweaks and minor corrections to the tutorial
Kennedy Clark [Thu, 21 Sep 2006 17:33:37 +0000 (17:33 +0000)]
lib/Catalyst/Manual/Tutorial/Authentication.pod
lib/Catalyst/Manual/Tutorial/BasicCRUD.pod

index b330fd7..5a87d9d 100644 (file)
@@ -806,7 +806,8 @@ is cleared (unless reset).  Although C<flash> has nothing to do with
 authentication, it does leverage the same session plugins.  Now that
 those plugins are enabled, let's go back and improve the "delete
 and redirect with query parameters" code seen at the end of the
-C<BasicCRUD> part of the tutorial.
+L<Basic CRUD|Catalyst::Manual::Tutorial::BasicCRUD> part of the 
+tutorial.
 
 First, open C<lib/MyApp/Controller/Books.pm> and modify C<sub delete>
 to match the following:
@@ -831,8 +832,8 @@ to match the following:
         $c->response->redirect($c->uri_for('/books/list'));
     }
 
-Next, open C<root/lib/site/layout> update the TT code to pull from flash
-vs. the C<status_msg> query parameter:
+Next, open C<root/lib/site/layout> and update the TT code to pull from 
+flash vs. the C<status_msg> query parameter:
 
     <div id="header">[% PROCESS site/header %]</div>
     
@@ -849,12 +850,12 @@ vs. the C<status_msg> query parameter:
 
 Restart the development server and point your browser to 
 L<http://localhost:3000/books/url_create/Test/1/4> to create an extra
-book.  Click the "Return to list" link and delete this "Test" book.  
-The C<flash> mechanism should retain our "Book deleted" status message
-across the redirect.
+book.  Click the "Return to list" link and delete this "Test" book you
+just added.  The C<flash> mechanism should retain our "Book deleted" 
+status message across the redirect.
 
 B<NOTE:> While C<flash> will save information across multiple requests,
-it does get cleared the first time it is read.  In general, this is
+I<it does get cleared the first time it is read>.  In general, this is
 exactly what you want -- the C<flash> message will get displayed on
 the next screen where it's appropriate, but it won't "keep showing up"
 after that first time (unless you reset it).  Please refer to
index 87ee086..d1ec819 100644 (file)
@@ -461,8 +461,8 @@ new request.  As a result, the URL in the browser is updated to match
 the destination of the redirection URL.
 
 To convert the forward used in the previous section to a redirect,
-open C<lib/MyApp/Controller/Books.pm> and the existing C<sub delete>
-method to match:
+open C<lib/MyApp/Controller/Books.pm> and edit the existing 
+C<sub delete> method to match:
 
     =head2 delete 
     
@@ -491,7 +491,8 @@ Restart the development server and point your browser to
 L<http://localhost:3000/books/list>.  Delete the first copy of 
 "TCPIP_Illustrated_Vol-2", but notice that I<no green "Book deleted" 
 status message is displayed>.  Because the stash is reset on every
-request, the C<status_msg> is cleared before it can be displayed.
+request (and a redirect involves a second request), the 
+C<status_msg> is cleared before it can be displayed.
 
 
 =head2 Using C<uri_for> to Pass Query Parameters
@@ -499,7 +500,7 @@ request, the C<status_msg> is cleared before it can be displayed.
 There are several ways to pass information across a redirect. 
 In general, the best option is to use the C<flash> technique that we
 will see in Part 4 of the tutorial; however, here we will pass the
-information via the redirect itself.  Open 
+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:
 
@@ -540,17 +541,18 @@ query parameter:
 =head2 Try the Delete and Redirect With Query Param Logic
 
 Restart the development server and point your browser to 
-L<http://localhost:3000/books/list> and delete the remaining copy of 
-"TCPIP_Illustrated_Vol-2".  The green "Book deleted" status message
+L<http://localhost:3000/books/list>.  Then delete the remaining copy 
+of "TCPIP_Illustrated_Vol-2".  The green "Book deleted" status message
 should return.
 
 B<NOTE:> Although this did present an opportunity to show a handy
 capability of C<uri_for>, it would be much better to use Catalyst's
-C<flash> feature in this situation.  Although less dangerous than 
-leaving the delete URL in the client's browser, we have still exposed 
-the status message to the user.  With C<flash>, this message returns 
-to its rightful place as a service-side mechanism (we will migrate
-this code to C<flash> in the next part of the tutorial).
+C<flash> feature in this situation.  Although the technique here is 
+less dangerous than  leaving the delete URL in the client's browser, 
+we have still exposed the status message to the user.  With C<flash>, 
+this message returns to its rightful place as a service-side 
+mechanism (we will migrate this code to C<flash> in the next part 
+of the tutorial).
 
 
 =head1 AUTHOR