files to the C<lib/MyApp/Schema/MyApp> directory. And, more
importantly, even if there were changes to the existing result source
files, those changes would have only been written above the C<# DO NOT
-MODIFY THIS OR ANYTHING ABOVE!> comment and your hand-editted
+MODIFY THIS OR ANYTHING ABOVE!> comment and your hand-edited
enhancements would have been preserved.
-Speaking of "hand-editted enhancements," we should now add
+Speaking of "hand-edit ted enhancements," we should now add
relationship information to the three new result source files. Edit
each of these files and add the following information between the C<#
DO NOT MODIFY THIS OR ANYTHING ABOVE!> comment and the closing C<1;>:
Session::State::Cookie
/);
+B<Note:> As discussed in MoreCatalystBasics, different versions of
+C<Catalyst::Devel> have used a variety of methods to load the plugins.
+You can put the plugins in the C<use Catalyst> statement if you prefer.
+
The C<Authentication> plugin supports Authentication while the
C<Session> plugins are required to maintain state across multiple HTTP
requests.
Then open C<lib/MyApp/Controller/Login.pm>, locate the C<sub index
:Path :Args(0)> method (or C<sub index : Private> if you are using an
older version of Catalyst) that was automatically inserted by the
-helpers when we created the Login controller above, and delete this
-line:
-
- $c->response->body('Matched MyApp::Controller::Login in Login.');
-
-Then update it to match:
+helpers when we created the Login controller above, and update the
+definition of C<sub index> to match:
=head2 index
my ($self, $c) = @_;
# Allow unauthenticated users to reach the login page. This
- # allows anauthenticated users to reach any action in the Login
+ # allows unauthenticated users to reach any action in the Login
# controller. To lock it down to a single action, we could use:
# if ($c->action eq $c->controller('Login')->action_for('index'))
# to only allow unauthenticated access to the 'index' action we
=item *
-The majority of application have traditionally used C<Local> actions
+The majority of applications have traditionally used C<Local> actions
for items that respond to user requests and C<Private> actions for
those that do not directly respond to user input.