and readable configuration files. It's a great way to keep your
Catalyst application configuration in one easy-to-understand location.
-Now create C<myapp.conf> in your application home:
+Now create F<myapp.conf> in your application home:
name MyApp
spaces in the filename are handled by the browser.
Put this right before calling C<< $c->res->body >> and your browser
-will download a file named C<Important Orders.csv> instead of
+will download a file named F<Important Orders.csv> instead of
C<export>.
You can also use this to have the browser download content which it
Static::Simple is a plugin that will help to serve static content for your
application. By default, it will serve most types of files, excluding some
standard Template Toolkit extensions, out of your B<root> file directory. All
-files are served by path, so if B<images/me.jpg> is requested, then
-B<root/images/me.jpg> is found and served.
+files are served by path, so if F<images/me.jpg> is requested, then
+F<root/images/me.jpg> is found and served.
=head3 Usage
=head3 Configuring
Static content is best served from a single directory within your root
-directory. Having many different directories such as C<root/css> and
-C<root/images> requires more code to manage, because you must separately
-identify each static directory--if you decide to add a C<root/js>
+directory. Having many different directories such as F<root/css> and
+F<root/images> requires more code to manage, because you must separately
+identify each static directory--if you decide to add a F<root/js>
directory, you'll need to change your code to account for it. In
contrast, keeping all static directories as subdirectories of a main
-C<root/static> directory makes things much easier to manage. Here's an
+F<root/static> directory makes things much easier to manage. Here's an
example of a typical root directory structure:
root/
root/static/js/code.js
-All static content lives under C<root/static>, with everything else being
+All static content lives under F<root/static>, with everything else being
Template Toolkit files.
=over 4
Next, create a controller to handle requests for the /static path. Use
the Helper to save time. This command will create a stub controller as
-C<lib/MyApp/Controller/Static.pm>.
+F<lib/MyApp/Controller/Static.pm>.
$ script/myapp_create.pl controller Static
When using Apache, you can bypass Catalyst and any Static
plugins/controllers controller by intercepting requests for the
-C<root/static> path at the server level. All that is required is to
+F<root/static> path at the server level. All that is required is to
define a DocumentRoot and add a separate Location block for your static
content. Here is a complete config for this application under mod_perl
1.x:
Catalyst provides a convenient way of testing your application during
development and before deployment in a real environment.
-C<Catalyst::Test> makes it possible to run the same tests both locally
+L<Catalyst::Test> makes it possible to run the same tests both locally
(without an external daemon) and against a remote server via HTTP.
=head3 Tests
-Let's examine a skeleton application's C<t/> directory:
+Let's examine a skeleton application's F<t/> directory:
mundus:~/MyApp chansen$ ls -l t/
total 24
=over 4
-=item C<01app.t>
+=item F<01app.t>
Verifies that the application loads, compiles, and returns a successful
response.
-=item C<02pod.t>
+=item F<02pod.t>
Verifies that all POD is free from errors. Only executed if the C<TEST_POD>
environment variable is true.
-=item C<03podcoverage.t>
+=item F<03podcoverage.t>
Verifies that all methods/functions have POD coverage. Only executed if the
C<TEST_POD> environment variable is true.
Catalyst provides a number of helper scripts that can be used to quickly
flesh out the basic structure of your application. All Catalyst projects
-begin with the C<catalyst.pl> helper (see
+begin with the F<catalyst.pl> helper (see
L<Catalyst::Helper> for more information on helpers).
Also note that as of Catalyst 5.7000, you will not have the helper
scripts unless you install both L<Catalyst::Runtime>
and L<Catalyst::Devel>.
-In this first chapter of the tutorial, use the Catalyst C<catalyst.pl>
+In this first chapter of the tutorial, use the Catalyst F<catalyst.pl>
script to initialize the framework for an application called C<Hello>:
$ catalyst.pl Hello
from the end of the "catalyst.pl" command and simply use
"catalyst Hello".
-The C<catalyst.pl> helper script will display the names of the
+The F<catalyst.pl> helper script will display the names of the
directories and files it creates:
Changes # Record of application changes
Catalyst will "auto-discover" modules in the Controller, Model, and View
-directories. When you use the C<hello_create.pl> script it will create Perl
+directories. When you use the F<hello_create.pl> script it will create Perl
module scaffolds in those directories, plus test files in the "t"
directory. The default location for templates is in the "root"
directory. The scripts in the script directory will always start with
=head2 The Simplest Way
The Root.pm controller is a place to put global actions that usually
-execute on the root URL. Open the C<lib/Hello/Controller/Root.pm> file
+execute on the root URL. Open the F<lib/Hello/Controller/Root.pm> file
in your editor. You will see the "index" subroutine, which is
responsible for displaying the welcome screen that you just saw in your
browser.
While you leave the C<script/hello_server.pl -r> command running the
development server in one window (don't forget the "-r" at the end!),
open another window and add the following subroutine to your
-C<lib/Hello/Controller/Root.pm> file:
+F<lib/Hello/Controller/Root.pm> file:
sub hello :Global {
my ( $self, $c ) = @_;
$ script/hello_create.pl view HTML TT
-This creates the C<lib/Hello/View/HTML.pm> module, which is a subclass
+This creates the F<lib/Hello/View/HTML.pm> module, which is a subclass
of C<Catalyst::View::TT>.
=over 4
=back
-If you look at C<lib/Hello/View/HTML.pm> you will find that it only
+If you look at F<lib/Hello/View/HTML.pm> you will find that it only
contains a config statement to set the TT extension to ".tt".
Now that the HTML.pm "View" exists, Catalyst will autodiscover it and be
explore some of the more common TT features in later chapters of the
tutorial).
-Create a C<root/hello.tt> template file (put it in the C<root> under the
+Create a F<root/hello.tt> template file (put it in the C<root> under the
C<Hello> directory that is the base of your application). Here is a
simple sample:
[% and %] are markers for the TT parts of the template. Inside you can
access Perl variables and classes, and use TT directives. In this case,
we're using a special TT variable that defines the name of the template
-file (C<hello.tt>). The rest of the template is normal HTML.
+file (F<hello.tt>). The rest of the template is normal HTML.
-Change the hello method in C<lib/Hello/Controller/Root.pm> to the
+Change the hello method in F<lib/Hello/Controller/Root.pm> to the
following:
sub hello :Global {
$ script/hello_create.pl controller Site
-This will create a C<lib/Hello/Controller/Site.pm> file (and a test
+This will create a F<lib/Hello/Controller/Site.pm> file (and a test
file). If you bring Site.pm up in your editor, you can see that
there's not much there to see.
-In C<lib/Hello/Controller/Site.pm>, add the following method:
+In F<lib/Hello/Controller/Site.pm>, add the following method:
sub test :Local {
my ( $self, $c ) = @_;
$ mkdir root/site
-Create a new template file in that directory named C<root/site/test.tt>
+Create a new template file in that directory named F<root/site/test.tt>
and include a line like:
<p>Hello, [% username %]!</p>
=head1 CREATE A NEW APPLICATION
The remainder of the tutorial will build an application called C<MyApp>.
-First use the Catalyst C<catalyst.pl> script to initialize the framework
+First use the Catalyst F<catalyst.pl> script to initialize the framework
for the C<MyApp> application (make sure you aren't still inside the
directory of the C<Hello> application from the previous chapter of the
tutorial or in a directory that already has a "MyApp" subdirectory):
object (generally written as C<$c>) that Catalyst passes to every
component throughout the framework.
-Take a look at the file C<lib/MyApp.pm> that the helper created above.
+Take a look at the file F<lib/MyApp.pm> that the helper created above.
By default, Catalyst enables three plugins/flags:
=over 4
C<-Debug> Flag
Enables the Catalyst debug output you saw when we started the
-C<script/myapp_server.pl> development server earlier. You can remove
+F<script/myapp_server.pl> development server earlier. You can remove
this item when you place your application into production.
To be technically correct, it turns out that C<-Debug> is not a plugin,
=item *
-the C<-d> option on the C<script/myapp_server.pl> script
+the C<-d> option on the F<script/myapp_server.pl> script
=item *
B<TIP>: Depending on your needs, it can be helpful to permanently remove
C<-Debug> from C<lib/MyApp.pm> and then use the C<-d> option to
-C<script/myapp_server.pl> to re-enable it when needed. We will not be
+F<script/myapp_server.pl> to re-enable it when needed. We will not be
using that approach in the tutorial, but feel free to make use of it in
your own projects.
Catalyst changed the default format from YAML to the more
straightforward C<Config::General> style. This tutorial uses the newer
C<myapp.conf> file for C<Config::General>. However, Catalyst supports
-both formats and will automatically use either C<myapp.conf> or
-C<myapp.yml> (or any other format supported by
+both formats and will automatically use either F<myapp.conf> or
+F<myapp.yml> (or any other format supported by
L<Catalyst::Plugin::ConfigLoader> and
L<Config::Any>). If you are using a version of
Catalyst::Devel prior to 1.06, you can convert to the newer format by
-simply creating the C<myapp.conf> file manually and deleting
-C<myapp.yml>. The default contents of the C<myapp.conf> you create
+simply creating the F<myapp.conf> file manually and deleting
+F<myapp.yml>. The default contents of the F<myapp.conf> you create
should only consist of one line:
name MyApp
=back
For our application, we want to add one new plugin to the mix. To do
-this, edit C<lib/MyApp.pm> (this file is generally referred to as your
+this, edit F<lib/MyApp.pm> (this file is generally referred to as your
I<application class>) and delete the lines with:
use Catalyst qw/
=item *
C<__PACKAGE__> is just a shorthand way of referencing the name of the
-package where it is used. Therefore, in C<MyApp.pm>, C<__PACKAGE__> is
+package where it is used. Therefore, in F<MyApp.pm>, C<__PACKAGE__> is
equivalent to C<MyApp>.
=item *
=item *
If you want to see what the StackTrace error screen looks like, edit
-C<lib/MyApp/Controller/Root.pm> and put a C<die "Oops";> command in the
+F<lib/MyApp/Controller/Root.pm> and put a C<die "Oops";> command in the
C<sub index :Path :Args(0)> method. Then start the development server
and open C<http://localhost:3000/> in your browser. You should get a
screen that starts with "Caught exception in
created "/home/catalyst/MyApp/script/../lib/MyApp/Controller/Books.pm"
created "/home/catalyst/MyApp/script/../t/controller_Books.t"
-Then edit C<lib/MyApp/Controller/Books.pm> (as discussed in
+Then edit F<lib/MyApp/Controller/Books.pm> (as discussed in
L<Chapter 2|Catalyst::Manual::Tutorial::02_CatalystBasics> of
-the Tutorial, Catalyst has a separate directory under C<lib/MyApp> for
+the Tutorial, Catalyst has a separate directory under F<lib/MyApp> for
each of the three parts of MVC: C<Model>, C<View> and C<Controller>)
and add the following method to the controller:
B<:Path> -- C<:Path> actions let you map a method to an explicit URI
path. For example, "C<:Path('list')>" in
-C<lib/MyApp/Controller/Books.pm> would match on the URL
+F<lib/MyApp/Controller/Books.pm> would match on the URL
C<http://localhost:3000/books/list>, but "C<:Path('/list')>" would match
on C<http://localhost:3000/list> (because of the leading slash). You
can use C<:Args()> to specify how many arguments an action should
As mentioned in L<Chapter 2|Catalyst::Manual::Tutorial::02_CatalystBasics>
of the tutorial, views are where you render output, typically for
display in the user's web browser (but can generate other types of
-output such as PDF or JSON). The code in C<lib/MyApp/View> selects the
+output such as PDF or JSON). The code in F<lib/MyApp/View> selects the
I<type> of view to use, with the actual rendering template found in the
C<root> directory. As with virtually every aspect of Catalyst, options
abound when it comes to the specific view technology you adopt inside
controls the overall "look and feel" of your site from a single file or
set of files).
-Edit C<lib/MyApp/View/HTML.pm> and you should see something similar to
+Edit F<lib/MyApp/View/HTML.pm> and you should see something similar to
the following:
__PACKAGE__->config(
'.tt2'.
You can also configure components in your application class. For
-example, Edit C<lib/MyApp.pm> and you should see the default
+example, Edit F<lib/MyApp.pm> and you should see the default
configuration above the call to C<< _PACKAGE__->setup >> (your defaults
could be different depending on the version of Catalyst you are using):
);
This changes the base directory for your template files from C<root> to
-C<root/src>.
+F<root/src>.
Please stick with the settings above for the duration of the tutorial,
but feel free to use whatever options you desire in your applications
(as with most things in Perl, there's more than one way to do it...).
-B<Note:> We will use C<root/src> as the base directory for our template
+B<Note:> We will use F<root/src> as the base directory for our template
files, with a full naming convention of
-C<root/src/_controller_name_/_action_name_.tt2>. Another popular option
-is to use C<root/> as the base (with a full filename pattern of
-C<root/_controller_name_/_action_name_.tt2>).
+F<root/src/_controller_name_/_action_name_.tt2>. Another popular option
+is to use F<root/> as the base (with a full filename pattern of
+F<root/_controller_name_/_action_name_.tt2>).
=head2 Create a TT Template Page
$ mkdir -p root/src/books
-Then create C<root/src/books/list.tt2> in your editor and enter:
+Then create F<root/src/books/list.tt2> in your editor and enter:
[% # This is a TT comment. -%]
In this step, we make a text file with the required SQL commands to
create a database table and load some sample data. We will use SQLite
(L<http://www.sqlite.org>), a popular database that is lightweight and
-easy to use. Be sure to get at least version 3. Open C<myapp01.sql> in
+easy to use. Be sure to get at least version 3. Open F<myapp01.sql> in
your editor and enter:
--
INSERT INTO book_author VALUES (4, 7);
INSERT INTO book_author VALUES (5, 8);
-Then use the following command to build a C<myapp.db> SQLite database:
+Then use the following command to build a F<myapp.db> SQLite database:
$ sqlite3 myapp.db < myapp01.sql
issue the C<rm myapp.db> command to delete the database before you use
the C<< sqlite3 myapp.db < myapp01.sql >> command.
-Once the C<myapp.db> database file has been created and initialized, you
+Once the F<myapp.db> database file has been created and initialized, you
can use the SQLite command line environment to do a quick dump of the
database contents:
$ perl -MCatalyst::Model::DBIC::Schema\ 999
$ perl -MDBD::SQLite\ 999
-Before you continue, make sure your C<myapp.db> database file is in the
+Before you continue, make sure your F<myapp.db> database file is in the
application's topmost directory. Now use the model helper with the
C<create=static> option to read the database with
L<DBIx::Class::Schema::Loader> and
able to cut and paste the text as shown or need to remove the '\'
character to that the command is all on a single line.
-The C<script/myapp_create.pl> command breaks down like this:
+The F<script/myapp_create.pl> command breaks down like this:
=over 4
=item *
C<DB> is the name of the model class to be created by the helper in
-the C<lib/MyApp/Model> directory.
+the F<lib/MyApp/Model> directory.
=item *
=item *
C<MyApp::Schema> is the name of the DBIC schema file written to
-C<lib/MyApp/Schema.pm>.
+F<lib/MyApp/Schema.pm>.
=item *
C<create=static> causes L<DBIx::Class::Schema::Loader> to load the
schema as it runs and then write that information out into
-C<lib/MyApp/Schema.pm> and files under the C<lib/MyApp/Schema>
+F<lib/MyApp/Schema.pm> and files under the F<lib/MyApp/Schema>
directory.
=item *
L<DBIx::Class::Schema::Loader> create
foreign key relationships for us (this is not needed for databases such
as PostgreSQL and MySQL, but is required for SQLite). If you take a look
-at C<lib/MyApp/Model/DB.pm>, you will see that the SQLite pragma is
+at F<lib/MyApp/Model/DB.pm>, you will see that the SQLite pragma is
propagated to the Model, so that SQLite's recent (and optional) foreign
key enforcement is enabled at the start of every database connection.
=back
-If you look in the C<lib/MyApp/Schema.pm> file, you will find that it
+If you look in the F<lib/MyApp/Schema.pm> file, you will find that it
only contains a call to the C<load_namespaces> method. You will also
-find that C<lib/MyApp> contains a C<Schema> subdirectory, which then has
+find that F<lib/MyApp> contains a C<Schema> subdirectory, which then has
a subdirectory called "Result". This "Result" subdirectory then has
files named according to each of the tables in our simple database
-(C<Author.pm>, C<BookAuthor.pm>, and C<Book.pm>). These three files are
+(F<Author.pm>, F<BookAuthor.pm>, and F<Book.pm>). These three files are
called "Result Classes" (or
"L<ResultSource Classes|DBIx::Class::ResultSource>") in DBIx::Class
nomenclature. Although the Result Class files are named after tables in
L<Catalyst::Manual::Tutorial::04_BasicCRUD/EXPLORING THE POWER OF DBIC>).
The idea with the Result Source files created under
-C<lib/MyApp/Schema/Result> by the C<create=static> option is to only
+F<lib/MyApp/Schema/Result> by the C<create=static> option is to only
edit the files below the C<# DO NOT MODIFY THIS OR ANYTHING ABOVE!>
warning. If you place all of your changes below that point in the file,
you can regenerate the automatically created information at the top of
Also note the "flow" of the model information across the various files
and directories. Catalyst will initially load the model from
-C<lib/MyApp/Model/DB.pm>. This file contains a reference to
-C<lib/MyApp/Schema.pm>, so that file is loaded next. Finally, the call
+F<lib/MyApp/Model/DB.pm>. This file contains a reference to
+F<lib/MyApp/Schema.pm>, so that file is loaded next. Finally, the call
to C<load_namespaces> in C<Schema.pm> will load each of the "Result
-Class" files from the C<lib/MyApp/Schema/Result> subdirectory. The
+Class" files from the F<lib/MyApp/Schema/Result> subdirectory. The
final outcome is that Catalyst will dynamically create three
table-specific Catalyst models every time the application starts (you
can see these three model files listed in the debug output generated
when you launch the application).
-Additionally, the C<lib/MyApp/Schema.pm> model can easily be loaded
+Additionally, the F<lib/MyApp/Schema.pm> model can easily be loaded
outside of Catalyst, for example, in command-line utilities and/or cron
-jobs. C<lib/MyApp/Model/DB.pm> provides a very thin "bridge" between
+jobs. F<lib/MyApp/Model/DB.pm> provides a very thin "bridge" between
Catalyst and this external database model. Once you see how we can
add some powerful features to our DBIC model in
L<Chapter 4|Catalyst::Manual::Tutorial::04_BasicCRUD>, the elegance
=head1 ENABLE THE MODEL IN THE CONTROLLER
-Open C<lib/MyApp/Controller/Books.pm> and un-comment the model code we
+Open F<lib/MyApp/Controller/Books.pm> and un-comment the model code we
left disabled earlier so that your version matches the following
(un-comment the line containing C<< [$c->model('DB::Book')->all] >>
and delete the next 2 lines):
[info] MyApp powered by Catalyst 5.80020
HTTP::Server::PSGI: Accepting connections at http://0:3000
-B<NOTE:> Be sure you run the C<script/myapp_server.pl> command from the
-'base' directory of your application, not inside the C<script> directory
-itself or it will not be able to locate the C<myapp.db> database file.
+B<NOTE:> Be sure you run the F<script/myapp_server.pl> command from the
+'base' directory of your application, not inside the F<script> directory
+itself or it will not be able to locate the F<myapp.db> database file.
You can use a fully qualified or a relative path to locate the database
file, but we did not specify that when we ran the model helper earlier.
Next, to view the book list, change the URL in your browser to
L<http://localhost:3000/books/list>. You should get a list of the five
-books loaded by the C<myapp01.sql> script above without any formatting.
+books loaded by the F<myapp01.sql> script above without any formatting.
The rating for each book should appear on each row, but the "Author(s)"
column will still be blank (we will fill that in later).
-Also notice in the output of the C<script/myapp_server.pl> that
+Also notice in the output of the F<script/myapp_server.pl> that
L<DBIx::Class> used the following SQL to retrieve the data:
SELECT me.id, me.title, me.rating FROM book me
In order to create a wrapper, you must first edit your TT view and tell
it where to find your wrapper file.
-Edit your TT view in C<lib/MyApp/View/HTML.pm> and change it to match
+Edit your TT view in F<lib/MyApp/View/HTML.pm> and change it to match
the following:
__PACKAGE__->config(
Next you need to set up your wrapper template. Basically, you'll want
to take the overall layout of your site and put it into this file. For
-the tutorial, open C<root/src/wrapper.tt2> and input the following:
+the tutorial, open F<root/src/wrapper.tt2> and input the following:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" [%#
C<< $c->stash->{status_msg} = 'Request was successful!' >>) it will
be displayed whenever any view used by that request is rendered. The
C<message> and C<error> CSS styles can be customized to suit your needs
-in the C<root/static/css/main.css> file we create below.
+in the F<root/static/css/main.css> file we create below.
B<Notes:>
$ mkdir root/static/css
-Then open the file C<root/static/css/main.css> (the file referenced in
+Then open the file F<root/static/css/main.css> (the file referenced in
the stylesheet href link of our wrapper above) and add the following
content:
Hit "Reload" in your web browser and you should now see a formatted
version of our basic book list. (Again, the development server should
have automatically restarted when you made changes to
-C<lib/MyApp/View/HTML.pm>. If you are not using the "-r" option, you
+F<lib/MyApp/View/HTML.pm>. If you are not using the "-r" option, you
will need to hit C<Ctrl-C> and manually restart it. Also note that the
development server does I<NOT> need to restart for changes to the TT and
static files we created and edited in the C<root> directory -- those
If you take a look at the Schema files automatically generated by
L<DBIx::Class::Schema::Loader>, you will see that it has already defined
C<has_many> and C<belongs_to> relationships on each side of our foreign
-keys. For example, take a look at C<lib/MyApp/Schema/Result/Book.pm> and
+keys. For example, take a look at F<lib/MyApp/Schema/Result/Book.pm> and
notice the following code:
=head1 RELATIONS
C<belongs_to> relationships. We recommend upgrading to the versions
specified above. :-)
-Have a look at C<lib/MyApp/Schema/Result/BookAuthor.pm> and notice that
+Have a look at F<lib/MyApp/Schema/Result/BookAuthor.pm> and notice that
there is a C<belongs_to> relationship defined that acts as the "mirror
image" to the C<has_many> relationship we just looked at above:
automatically handle the C<has_many> and C<belongs_to> relationships,
C<many_to_many> relationship bridges (not technically a relationship)
currently need to be manually inserted. To add a C<many_to_many>
-relationship bridge, first edit C<lib/MyApp/Schema/Result/Book.pm> and
+relationship bridge, first edit F<lib/MyApp/Schema/Result/Book.pm> and
add the following text below the C<# You can replace this text...>
comment:
define a C<many_to_many> relationship bridge without also having the
C<has_many> relationship in place.
-Then edit C<lib/MyApp/Schema/Result/Author.pm> and add the reverse
+Then edit F<lib/MyApp/Schema/Result/Author.pm> and add the reverse
C<many_to_many> relationship bridge for C<Author> as follows (again, be
careful to put in above the C<1;> but below the C<# DO NOT MODIFY THIS
OR ANYTHING ABOVE!> comment):
Let's add a new column to our book list page that takes advantage of the
relationship information we manually added to our schema files in the
-previous section. Edit C<root/src/books/list.tt2> and replace the
+previous section. Edit F<root/src/books/list.tt2> and replace the
"empty" table cell "<td></td>" with the following:
...
SELECT author.id, author.first_name, author.last_name FROM book_author me
JOIN author author ON author.id = me.author_id WHERE ( me.book_id = ? ): '5'
-Also note in C<root/src/books/list.tt2> that we are using "| html", a
+Also note in F<root/src/books/list.tt2> that we are using "| html", a
type of TT filter, to escape characters such as < and > to <
and > and avoid various types of dangerous hacks against your
application. In a real application, you would probably want to put "|
In some situations, it can be useful to run your application and display
a page without using a browser. Catalyst lets you do this using the
-C<script/myapp_test.pl> script. Just supply the URL you wish to
+F<script/myapp_test.pl> script. Just supply the URL you wish to
display and it will run that request through the normal controller
dispatch logic and use the appropriate view to render the output
(obviously, complex pages may dump a lot of text to your terminal
response output. Catalyst uses
L<Catalyst::Action::RenderView> by default
to automatically perform this operation. If you look in
-C<lib/MyApp/Controller/Root.pm>, you should see the empty definition for
+F<lib/MyApp/Controller/Root.pm>, you should see the empty definition for
the C<sub end> method:
sub end : ActionClass('RenderView') {}
=item *
-C<Root.pm> is designed to hold application-wide logic.
+F<Root.pm> is designed to hold application-wide logic.
=item *
C<end> method that's appropriate. For example, if the controller for a
request has an C<end> method defined, it will be called. However, if
the controller does not define a controller-specific C<end> method, the
-"global" C<end> method in C<Root.pm> will be called.
+"global" C<end> method in F<Root.pm> will be called.
=item *
logic in C<RenderView>. However, you can easily extend the
C<RenderView> logic by adding your own code inside the empty method body
(C<{}>) created by the Catalyst Helpers when we first ran the
-C<catalyst.pl> to initialize our application. See
+F<catalyst.pl> to initialize our application. See
L<Catalyst::Action::RenderView> for more
detailed information on how to extend C<RenderView> in C<sub end>.
In order to be able to use C<< $c->forward >> and C<< $c->detach >>
later in the tutorial, you should remove the comment from the statement
-in C<sub list> in C<lib/MyApp/Controller/Books.pm>:
+in C<sub list> in F<lib/MyApp/Controller/Books.pm>:
$c->stash(template => 'books/list.tt2');
-Then delete the C<TEMPLATE_EXTENSION> line in C<lib/MyApp/View/HTML.pm>.
+Then delete the C<TEMPLATE_EXTENSION> line in F<lib/MyApp/View/HTML.pm>.
Check the L<http://localhost:3000/books/list> URL in your browser. It
should look the same manner as with earlier sections.
=head2 Include a Create Action in the Books Controller
-Edit C<lib/MyApp/Controller/Books.pm> and enter the following method:
+Edit F<lib/MyApp/Controller/Books.pm> and enter the following method:
=head2 url_create
Also note that we are explicitly setting a C<no-cache> "Cache-Control"
header to force browsers using the page to get a fresh copy every time.
You could even move this to a C<auto> method in
-C<lib/MyApp/Controller/Root.pm> and it would automatically get applied
+F<lib/MyApp/Controller/Root.pm> and it would automatically get applied
to every page in the whole application via a single line of code
(remember from Chapter 3, that every C<auto> method gets run in the
Controller hierarchy).
=head2 Include a Template for the 'url_create' Action:
-Edit C<root/src/books/create_done.tt2> and then enter:
+Edit F<root/src/books/create_done.tt2> and then enter:
[% # Use the TT Dumper plugin to Data::Dumper variables to the browser -%]
[% # Not a good idea for production use, though. :-) 'Indent=1' is -%]
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 entered above
+for C<url_create> in F<lib/MyApp/Controller/Books.pm> you entered above
to match the following:
sub url_create :Chained('/') :PathPart('books/url_create') :Args(3) {
Let's make a quick update to our initial Chained action to show a little
more of the power of chaining. First, open
-C<lib/MyApp/Controller/Books.pm> in your editor and add the following
+F<lib/MyApp/Controller/Books.pm> in your editor and add the following
method:
=head2 base
C<object> action shortly.
As for C<url_create>, let's modify it to first dispatch to C<base>.
-Open up C<lib/MyApp/Controller/Books.pm> and edit the declaration for
+Open up F<lib/MyApp/Controller/Books.pm> and edit the declaration for
C<url_create> to match the following:
sub url_create :Chained('base') :PathPart('url_create') :Args(3) {
-Once you save C<lib/MyApp/Controller/Books.pm>, notice that the
+Once you save F<lib/MyApp/Controller/Books.pm>, notice that the
development server will restart and our "Loaded Chained actions" section
will changed slightly:
"create" actions more than once. Don't worry about it as long as the
number of books is appropriate for the number of times you added new
books... there should be the original five books added via
-C<myapp01.sql> plus one additional book for each time you ran one of the
+F<myapp01.sql> plus one additional book for each time you ran one of the
url_create variations above.)
=head2 Add Method to Display The Form
-Edit C<lib/MyApp/Controller/Books.pm> and add the following method:
+Edit F<lib/MyApp/Controller/Books.pm> and add the following method:
=head2 form_create
=head2 Add a Template for the Form
-Open C<root/src/books/form_create.tt2> in your editor and enter:
+Open F<root/src/books/form_create.tt2> in your editor and enter:
[% META title = 'Manual Form Book Create' -%]
=head2 Add a Method to Process Form Values and Update Database
-Edit C<lib/MyApp/Controller/Books.pm> and add the following method to
+Edit F<lib/MyApp/Controller/Books.pm> and add the following method to
save the form information to the database:
=head2 form_create_do
Point your browser to L<http://localhost:3000/books/form_create> and
enter "TCP/IP Illustrated, Vol 3" for the title, a rating of 5, and an
author ID of 4. You should then see the output of the same
-C<create_done.tt2> template seen in earlier examples. Finally, click
+F<create_done.tt2> template seen in earlier examples. Finally, click
"Return to list" to view the full list of books.
B<Note:> Having the user enter the primary key ID for the author is
=head2 Include a Delete Link in the List
-Edit C<root/src/books/list.tt2> and update it to match the following
+Edit F<root/src/books/list.tt2> and update it to match the following
(two sections have changed: 1) the additional '<th>Links</th>' table
header, and 2) the five lines for the Delete link near the bottom):
C<url_create> that don't operate on an existing book can chain directly
off base.
-To add the C<object> method, edit C<lib/MyApp/Controller/Books.pm> and
+To add the C<object> method, edit F<lib/MyApp/Controller/Books.pm> and
add the following code:
=head2 object
=head2 Add a Delete Action to the Controller
-Open C<lib/MyApp/Controller/Books.pm> in your editor and add the
+Open F<lib/MyApp/Controller/Books.pm> in your editor and add the
following method:
=head2 delete
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 edit the existing C<sub delete>
+F<lib/MyApp/Controller/Books.pm> and edit the existing C<sub delete>
method to match:
=head2 delete
L<Chapter 5|Catalyst::Manual::Tutorial::05_Authentication> of this
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>
+F<lib/MyApp/Controller/Books.pm> and update the existing C<sub delete>
method to match the following:
=head2 delete
This modification simply leverages the ability of C<uri_for> to include
an arbitrary number of name/value pairs in a hash reference. Next, we
-need to update C<root/src/wrapper.tt2> to handle C<status_msg> as a
+need to update F<root/src/wrapper.tt2> to handle C<status_msg> as a
query parameter:
...
...
Although the sample above only shows the C<content> div, leave the rest
-of the file intact -- the only change we made to the C<wrapper.tt2> was
+of the file intact -- the only change we made to the F<wrapper.tt2> was
to add "C<|| c.request.params.status_msg>" to the
C<< <span class="message"> >> line. Note that we definitely want
the "C<| html>" TT filter here since it would be easy for users to
include the L<DBIx::Class::TimeStamp> in the C<load_components> line of
the Result Classes.
-If you open C<lib/MyApp/Schema/Result/Book.pm> in your editor you should
+If you open F<lib/MyApp/Schema/Result/Book.pm> in your editor you should
see that the C<created> and C<updated> fields are now included in the
call to C<add_columns()>. However, also notice that the C<many_to_many>
relationships we manually added below the "C<# DO NOT MODIFY...>" line
were automatically preserved.
-While we C<lib/MyApp/Schema/Result/Book.pm> open, let's update it with
+While we F<lib/MyApp/Schema/Result/Book.pm> open, let's update it with
some additional information to have DBIC automatically handle the
updating of these two fields for us. Insert the following code at the
bottom of the file (it B<must> be B<below> the "C<# DO NOT MODIFY...>"
B<Note> that adding the lines above will cause the development server to
automatically restart if you are running it with the "-r" option. In
other words, the development server is smart enough to restart not only
-for code under the C<MyApp/Controller/>, C<MyApp/Model/>, and
-C<MyApp/View/> directories, but also under other directions such as our
-"external DBIC model" in C<MyApp/Schema/>. However, also note that it's
+for code under the F<MyApp/Controller/>, F<MyApp/Model/>, and
+F<MyApp/View/> directories, but also under other directions such as our
+"external DBIC model" in F<MyApp/Schema/>. However, also note that it's
smart enough to B<not> restart when you edit your C<.tt2> files under
-C<root/>.
+F<root/>.
Then enter the following URL into your web browser:
$ mkdir lib/MyApp/Schema/ResultSet
-Then open C<lib/MyApp/Schema/ResultSet/Book.pm> and enter the following:
+Then open F<lib/MyApp/Schema/ResultSet/Book.pm> and enter the following:
package MyApp::Schema::ResultSet::Book;
1;
-Then add the following method to the C<lib/MyApp/Controller/Books.pm>:
+Then add the following method to the F<lib/MyApp/Controller/Books.pm>:
=head2 list_recent
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<Books> controller that lists books that are both recent I<and> have
-"TCP" in the title. Open up C<lib/MyApp/Controller/Books.pm> and add
+"TCP" in the title. Open up F<lib/MyApp/Controller/Books.pm> and add
the following method:
=head2 list_recent_tcp
However, let's not pollute our controller code with this raw "TCP" query
-- it would be cleaner to encapsulate that code in a method on our
-ResultSet Class. To do this, open C<lib/MyApp/Schema/ResultSet/Book.pm>
+ResultSet Class. To do this, open F<lib/MyApp/Schema/ResultSet/Book.pm>
and add the following method:
=head2 title_like
We defined the search string as C<$title_str> to make the method more
flexible. Now update the C<list_recent_tcp> method in
-C<lib/MyApp/Controller/Books.pm> to match the following (we have
+F<lib/MyApp/Controller/Books.pm> to match the following (we have
replaced the C<< ->search >> line with the C<< ->title_like >> line
shown here -- the rest of the method should be the same):
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<lib/MyApp/Schema/Result/>. For example, open
-C<lib/MyApp/Schema/Result/Author.pm> and add the following method (as
+Classes stored in F<lib/MyApp/Schema/Result/>. For example, open
+F<lib/MyApp/Schema/Result/Author.pm> and add the following method (as
always, it must be above the closing "C<1;>"):
#
}
This will allow us to conveniently retrieve both the first and last name
-for an author in one shot. Now open C<root/src/books/list.tt2> and
+for an author in one shot. Now open F<root/src/books/list.tt2> and
change the definition of C<tt_authors> from this:
...
The previous section illustrated how we could use a Result Class method
to print the full names of the authors without adding any extra code to
our view, but it still left us with a fairly ugly mess (see
-C<root/src/books/list.tt2>):
+F<root/src/books/list.tt2>):
...
<td>
Let's combine some of the techniques used earlier in this section to
clean this up. First, let's add a method to our Book Result Class to
return the number of authors for a book. Open
-C<lib/MyApp/Schema/Result/Book.pm> and add the following method:
+F<lib/MyApp/Schema/Result/Book.pm> and add the following method:
=head2 author_count
}
Next, let's add a method to return a list of authors for a book to the
-same C<lib/MyApp/Schema/Result/Book.pm> file:
+same F<lib/MyApp/Schema/Result/Book.pm> file:
=head2 author_list
}
This method loops through each author, using the C<full_name> Result
-Class method we added to C<lib/MyApp/Schema/Result/Author.pm> in the
+Class method we added to F<lib/MyApp/Schema/Result/Author.pm> in the
prior section.
Using these two methods, we can simplify our TT code. Open
-C<root/src/books/list.tt2> and update the "Author(s)" table cell to
+F<root/src/books/list.tt2> and update the "Author(s)" table cell to
match the following:
...
First, we add both user and role information to the database (we will
add the role information here although it will not be used until the
authorization section, Chapter 6). Create a new SQL script file by
-opening C<myapp02.sql> in your editor and insert:
+opening F<myapp02.sql> in your editor and insert:
--
-- Add users and role tables, along with a many-to-many join table
INSERT INTO user_role VALUES (2, 1);
INSERT INTO user_role VALUES (3, 1);
-Then load this into the C<myapp.db> database with the following command:
+Then load this into the F<myapp.db> database with the following command:
$ sqlite3 myapp.db < myapp02.sql
Author.pm BookAuthor.pm Book.pm Role.pm User.pm UserRole.pm
Notice how the helper has added three new table-specific Result Source
-files to the C<lib/MyApp/Schema/Result> directory. And, more
+files to the F<lib/MyApp/Schema/Result> 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-edited
tables. However, as a convenience for mapping Users to their assigned
roles (see L<Chapter 6|Catalyst::Manual::Tutorial::06_Authorization>),
we will also manually add a C<many_to_many> relationship. Edit
-C<lib/MyApp/Schema/Result/User.pm> add the following information between
+F<lib/MyApp/Schema/Result/User.pm> add the following information between
the C<# DO NOT MODIFY THIS OR ANYTHING ABOVE!> comment and the closing
C<1;>:
C<many_to_many> in the Users to Roles direction.
Note that we do not need to make any change to the
-C<lib/MyApp/Schema.pm> schema file. It simply tells DBIC to load all of
+F<lib/MyApp/Schema.pm> schema file. It simply tells DBIC to load all of
the Result Class and ResultSet Class files it finds below the
-C<lib/MyApp/Schema> directory, so it will automatically pick up our new
+F<lib/MyApp/Schema> directory, so it will automatically pick up our new
table information.
=head2 Include Authentication and Session Plugins
-Edit C<lib/MyApp.pm> and update it as follows (everything below
+Edit F<lib/MyApp.pm> and update it as follows (everything below
C<StackTrace> is new):
# Load plugins
sets a reasonable set of defaults for us. (Note: the C<SimpleDB> here
has nothing to do with the SimpleDB offered in Amazon's web services
offerings -- here we are only talking about a "simple" way to use your
-DB as an authentication backend.) Open C<lib/MyApp.pm> and place the
+DB as an authentication backend.) Open F<lib/MyApp.pm> and place the
following text above the call to C<< __PACKAGE__->setup(); >>:
# Configure SimpleDB Authentication
},
);
-We could have placed this configuration in C<myapp.conf>, but placing it
-in C<lib/MyApp.pm> is probably a better place since it's not likely
+We could have placed this configuration in F<myapp.conf>, but placing it
+in F<lib/MyApp.pm> is probably a better place since it's not likely
something that users of your application will want to change during
deployment (or you could use a mixture: leave C<class> and C<user_model>
-defined in C<lib/MyApp.pm> as we show above, but place C<password_type>
-in C<myapp.conf> to allow the type of password to be easily modified
+defined in F<lib/MyApp.pm> as we show above, but place C<password_type>
+in F<myapp.conf> to allow the type of password to be easily modified
during deployment). We will stick with putting all of the
-authentication-related configuration in C<lib/MyApp.pm> for the
-tutorial, but if you wish to use C<myapp.conf>, just convert to the
+authentication-related configuration in F<lib/MyApp.pm> for the
+tutorial, but if you wish to use F<myapp.conf>, just convert to the
following code:
<Plugin::Authentication>
</Plugin::Authentication>
B<TIP:> Here is a short script that will dump the contents of
-C<MyApp->config> to L<Config::General> format in C<myapp.conf>:
+C<MyApp->config> to L<Config::General> format in F<myapp.conf>:
$ CATALYST_DEBUG=0 perl -Ilib -e 'use MyApp; use Config::General;
Config::General->new->save_file("myapp.conf", MyApp->config);'
Remember, Catalyst is designed to be very flexible, and leaves such
matters up to you, the designer and programmer.
-Then open C<lib/MyApp/Controller/Login.pm>, and update the definition of
+Then open F<lib/MyApp/Controller/Login.pm>, and update the definition of
C<sub index> to match:
=head2 index
on I<only> C</login>, not C</login/somethingelse>.
Next, update the corresponding method in
-C<lib/MyApp/Controller/Logout.pm> to match:
+F<lib/MyApp/Controller/Logout.pm> to match:
=head2 index
=head2 Add a Login Form TT Template Page
-Create a login form by opening C<root/src/login.tt2> and inserting:
+Create a login form by opening F<root/src/login.tt2> and inserting:
[% META title = 'Login' %]
mechanism -- a I<global> mechanism that prevents users who have not
passed authentication from reaching any pages except the login page.
This is generally done via an C<auto> action/method in
-C<lib/MyApp/Controller/Root.pm>.
+F<lib/MyApp/Controller/Root.pm>.
-Edit the existing C<lib/MyApp/Controller/Root.pm> class file and insert
+Edit the existing F<lib/MyApp/Controller/Root.pm> class file and insert
the following method:
=head2 auto
every C<auto> method from the application/root controller down to the
most specific controller will be called. By placing the authentication
enforcement code inside the C<auto> method of
-C<lib/MyApp/Controller/Root.pm> (or C<lib/MyApp.pm>), it will be called
+F<lib/MyApp/Controller/Root.pm> (or F<lib/MyApp.pm>), it will be called
for I<every> request that is received by the entire application.
Let's say you want to provide some information on the login page that
changes depending on whether the user has authenticated yet. To do
-this, open C<root/src/login.tt2> in your editor and add the following
+this, open F<root/src/login.tt2> in your editor and add the following
lines to the bottom of the file:
...
Worse case, you might have to manually set the time on your development
box instead of using NTP.
-Open C<root/src/books/list.tt2> and add the following lines to the
+Open F<root/src/books/list.tt2> and add the following lines to the
bottom (below the closing </table> tag):
...
If you then open one of the Result Classes, you will see that it
includes PassphraseColumn in the C<load_components> line. Take a look
-at C<lib/MyApp/Schema/Result/User.pm> since that's the main class where
+at F<lib/MyApp/Schema/Result/User.pm> since that's the main class where
we want to use hashed and salted passwords:
__PACKAGE__->load_components("InflateColumn::DateTime", "TimeStamp", "PassphraseColumn");
=head2 Modify the "password" Column to Use PassphraseColumn
-Open the file C<lib/MyApp/Schema/Result/User.pm> and enter the following
+Open the file F<lib/MyApp/Schema/Result/User.pm> and enter the following
text below the "# DO NOT MODIFY THIS OR ANYTHING ABOVE!" line but above
the closing "1;":
Next, let's create a quick script to load some hashed and salted
passwords into the C<password> column of our C<users> table. Open the
-file C<set_hashed_passwords.pl> in your editor and enter the following
+file F<set_hashed_passwords.pl> in your editor and enter the following
text:
#!/usr/bin/perl
$ DBIC_TRACE=1 perl -Ilib set_hashed_passwords.pl
We had to use the C<-Ilib> argument to tell Perl to look under the
-C<lib> directory for our C<MyApp::Schema> model.
+F<lib> directory for our C<MyApp::Schema> model.
The DBIC_TRACE output should show that the update worked:
=head2 Enable Hashed and Salted Passwords
-Edit C<lib/MyApp.pm> and update the config() section for
+Edit F<lib/MyApp.pm> and update the config() section for
C<Plugin::Authentication> it to match the following text (the only
change is to the C<password_type> field):
Catalyst::Plugin::Authentication::Store::DBIx::Class to call the
C<check_password> method we enabled on our C<password> columns.
-
=head2 Try Out the Hashed Passwords
The development server should restart as soon as your save the
-C<lib/MyApp.pm> file in the previous section. You should now be able to
+F<lib/MyApp.pm> file in the previous section. You should now be able to
go to L<http://localhost:3000/books/list> and login as before. When
done, click the "logout" link on the login page (or point your browser
at L<http://localhost:3000/logout>).
L<Basic CRUD|Catalyst::Manual::Tutorial::04_BasicCRUD> chapter of the
tutorial to take advantage of C<flash>.
-First, open C<lib/MyApp/Controller/Books.pm> and modify C<sub delete> to
+First, open F<lib/MyApp/Controller/Books.pm> and modify C<sub delete> to
match the following (everything after the model search line of code has
changed):
$c->response->redirect($c->uri_for($self->action_for('list')));
}
-Next, open C<root/src/wrapper.tt2> and update the TT code to pull from
+Next, open F<root/src/wrapper.tt2> and update the TT code to pull from
flash vs. the C<status_msg> query parameter:
...
it's only displayed the first time). The use of C<StatusMessage>
or a similar mechanism is recommended for all Catalyst applications.
-To enable C<StatusMessage>, first edit C<lib/MyApp.pm> and add
+To enable C<StatusMessage>, first edit F<lib/MyApp.pm> and add
C<StatusMessage> to the list of plugins:
use Catalyst qw/
StatusMessage
/;
-Then edit C<lib/MyApp/Controller/Books.pm> and modify the C<delete>
+Then edit F<lib/MyApp/Controller/Books.pm> and modify the C<delete>
action to match the following:
sub delete :Chained('object') :PathPart('delete') :Args(0) {
message. The easiest way to do this is to take advantage of the chained
dispatch we implemented in
L<Chapter 4|Catalyst::Manual::Tutorial::04_BasicCRUD>. Edit
-C<lib/MyApp/Controller/Books.pm> again and update the C<base> action to
+F<lib/MyApp/Controller/Books.pm> again and update the C<base> action to
match:
sub base :Chained('/') :PathPart('books') :CaptureArgs(0) {
sub list :Chained('base') :PathPart('list') :Args(0) {
Finally, let's clean up the status/error message code in our wrapper
-template. Edit C<root/src/wrapper.tt2> and change the "content" div
+template. Edit F<root/src/wrapper.tt2> and change the "content" div
to match the following:
<div id="content">
$ prove -wl t
There will be a lot of output because we have the C<-Debug> flag enabled
-in C<lib/MyApp.pm> (see the C<CATALYST_DEBUG=0> tip below for a quick
+in F<lib/MyApp.pm> (see the C<CATALYST_DEBUG=0> tip below for a quick
and easy way to reduce the clutter). Look for lines like this for
errors:
failures in the default tests. You can fix this by making the following
changes:
-1) Change the line in C<t/01app.t> that reads:
+1) Change the line in F<t/01app.t> that reads:
ok( request('/')->is_success, 'Request should succeed' );
ok( request('/login')->is_success, 'Request should succeed' );
-2) Change the line in C<t/controller_Logout.t> that reads:
+2) Change the line in F<t/controller_Logout.t> that reads:
ok( request('/logout')->is_success, 'Request should succeed' );
ok( request('/logout')->is_redirect, 'Request should succeed' );
-3) Change the line in C<t/controller_Books.t> that reads:
+3) Change the line in F<t/controller_Books.t> that reads:
ok( request('/books')->is_success, 'Request should succeed' );
ok( request('/books')->is_redirect, 'Request should succeed' );
-4) Add the following statement to the top of C<t/view_HTML.t>:
+4) Add the following statement to the top of F<t/view_HTML.t>:
use MyApp;
C<--lib> if you prefer) is used to set the location of the Catalyst
C<lib> directory. With this command, you will get all of the usual
development server debug output, something most people prefer to disable
-while running tests cases. Although you can edit the C<lib/MyApp.pm> to
+while running tests cases. Although you can edit the F<lib/MyApp.pm> to
comment out the C<-Debug> plugin, it's generally easier to simply set
the C<CATALYST_DEBUG=0> environment variable. For example:
$ CATALYST_DEBUG=0 prove -wl t
-During the C<t/02pod> and C<t/03podcoverage> tests, you might notice the
+During the F<t/02pod.t> and F<t/03podcoverage.t> tests, you might notice the
C<all skipped: set TEST_POD to enable this test> warning message. To
execute the Pod-related tests, add C<TEST_POD=1> to the C<prove>
command:
benefits of testing on a live system without the messiness of having to
use an actual web server, and a real person to do the clicking.
-To create a sample test case, open the C<t/live_app01.t> file in your
+To create a sample test case, open the F<t/live_app01.t> file in your
editor and enter the following:
#!/usr/bin/env perl
done_testing;
-The C<live_app.t> test cases uses copious comments to explain each step
+The F<live_app.t> test cases uses copious comments to explain each step
of the process. In addition to the techniques shown here, there are a
variety of other methods available in L<Test::WWW::Mechanize::Catalyst>
(for example, regex-based matching). Consult
One solution is to allow the database specification to be overridden
with an environment variable. For example, open
-C<lib/MyApp/Model/DB.pm> in your editor and change the
+F<lib/MyApp/Model/DB.pm> in your editor and change the
C<< __PACKAGE__->config(... >> declaration to resemble:
my $dsn = $ENV{MYAPP_DSN} ||= 'dbi:SQLite:myapp.db';
Setting C<$ENV{ MYAPP_CONFIG_LOCAL_SUFFIX }> to 'testing' in your test
script results in loading of an additional config file named
-C<myapp_testing.conf> after C<myapp.conf> which will override any
-parameters in C<myapp.conf>.
+F<myapp_testing.conf> after F<myapp.conf> which will override any
+parameters in F<myapp.conf>.
You should set the environment variable in the BEGIN block of your test
script to make sure it's set before your Catalyst application is
=head2 Inherit From Catalyst::Controller::HTML::FormFu
-First, change your C<lib/MyApp/Controller/Books.pm> to inherit from
+First, change your F<lib/MyApp/Controller/Books.pm> to inherit from
L<Catalyst::Controller::HTML::FormFu> by changing the C<extends> line
from the default of:
=head2 Add Action to Display and Save the Form
-Open C<lib/MyApp/Controller/Books.pm> in your editor and add the
+Open F<lib/MyApp/Controller/Books.pm> in your editor and add the
following method:
=head2 formfu_create
$ mkdir -p root/forms/books
-Then create the file C<root/forms/books/formfu_create.yml> and enter the
+Then create the file F<root/forms/books/formfu_create.yml> and enter the
following text:
---
value: Submit
B<NOTE:> Copying and pasting YAML from Perl documentation is sometimes
-tricky. See the L<Config::General Config for this tutorial> section of
+tricky. See the L</Config::General Config for this tutorial> section of
this document for a more foolproof config format.
=head2 Update the CSS
-Edit C<root/static/css/main.css> and add the following lines to the
+Edit F<root/static/css/main.css> and add the following lines to the
bottom of the file:
...
=head2 Create a Template Page To Display The Form
-Open C<root/src/books/formfu_create.tt2> in your editor and enter the
+Open F<root/src/books/formfu_create.tt2> in your editor and enter the
following:
[% META title = 'Create/Update Book' %]
=head2 Add Links for Create and Update via C<HTML::FormFu>
-Open C<root/src/books/list.tt2> in your editor and add the following to
+Open F<root/src/books/list.tt2> in your editor and add the following to
the bottom of the existing file:
...
=head2 Add Constraints
-Open C<root/forms/books/formfu_create.yml> in your editor and update it
+Open F<root/forms/books/formfu_create.yml> in your editor and update it
to match:
---
The C<Select> element for C<authors> is changed from a single-select
drop-down to a multi-select list by adding configuration for the
-C<multiple> and C<size> options in C<formfu_create.yml>.
+C<multiple> and C<size> options in F<formfu_create.yml>.
=item *
=head1 CREATE AND UPDATE/EDIT ACTION
Let's expand the work done above to add an edit action. First, open
-C<lib/MyApp/Controller/Books.pm> and add the following method to the
+F<lib/MyApp/Controller/Books.pm> and add the following method to the
bottom:
=head2 formfu_edit
We have to manually specify the name of the FormFu .yml file as an
argument to C<:FormConfig> because the name can no longer be
automatically deduced from the name of our action/method (by default,
-FormFu would look for a file named C<books/formfu_edit.yml>).
+FormFu would look for a file named F<books/formfu_edit.yml>).
=item *
=back
-Then, edit C<root/src/books/list.tt2> and add a new link below the
+Then, edit F<root/src/books/list.tt2> and add a new link below the
existing "Delete" link that allows us to edit/update each existing book.
The last <td> cell in the book list table should look like the
following:
=head2 Config::General Config for this tutorial
If you are having difficulty with YAML config above, please save the
-below into the file C<formfu_create.conf> and delete the
-C<formfu_create.yml> file. The below is in L<Config::General> format
+below into the file F<formfu_create.conf> and delete the
+F<formfu_create.yml> file. The below is in L<Config::General> format
which follows the syntax of Apache config files.
constraints Required
requires 'HTML::FormHandler::Model::DBIC';
-to your C<Makefile.PL>.
+to your F<Makefile.PL>.
=head1 HTML::FormHandler FORM CREATION
=head2 Create a Book Form
-Create the directory C<lib/MyApp/Form>. Create C<lib/MyApp/Form/Book.pm>:
+Create the directory F<lib/MyApp/Form>. Create F<lib/MyApp/Form/Book.pm>:
package MyApp::Form::Book;
=head2 Add Action to Display and Save the Form
-At the top of the C<lib/MyApp/Controller/Books.pm> add:
+At the top of the F<lib/MyApp/Controller/Books.pm> add:
use MyApp::Form::Book;
=head2 Create a Template Page To Display The Form
-Open C<root/src/books/form.tt2> in your editor and enter the following:
+Open F<root/src/books/form.tt2> in your editor and enter the following:
[% META title = 'Create/Update Book' %]
=head2 Add Link for Create
-Open C<root/src/books/list.tt2> in your editor and add the following to
+Open F<root/src/books/list.tt2> in your editor and add the following to
the bottom of the existing file:
...
=head2 Add Constraints
-Open C<lib/MyApp/Form/Book.pm> in your editor.
+Open F<lib/MyApp/Form/Book.pm> in your editor.
Restrict the title size and make it required:
=head2 Create the 'edit' method
-Edit C<lib/MyApp/Controller/Books.pm> and add the following method:
+Edit F<lib/MyApp/Controller/Books.pm> and add the following method:
=head2 edit
return $self->form($c, $c->stash->{object});
}
-Update the C<root/src/books/list.tt2>, adding an 'edit' link below the
+Update the F<root/src/books/list.tt2>, adding an 'edit' link below the
"Delete" link to use the FormHandler edit method:
<td>
sudo aptitude install postgresql libdbd-pg-perl libdatetime-format-pg-perl
To configure the permissions, you can open
-C</etc/postgresql/8.3/main/pg_hba.conf> and change this line (near the
+F</etc/postgresql/8.3/main/pg_hba.conf> and change this line (near the
bottom):
# "local" is for Unix domain socket connections only
=item *
-Open the C<myapp01_psql.sql> in your editor and enter:
+Open the F<myapp01_psql.sql> in your editor and enter:
--
-- Drops just in case you are reloading
Create the C<.sql> file for the user/roles data:
-Open C<myapp02_psql.sql> in your editor and enter:
+Open F<myapp02_psql.sql> in your editor and enter:
--
-- Add users and roles tables, along with a many-to-many join table
=item *
-Modify C<set_hashed_passwords.pl> to match the following (the only difference
+Modify F<set_hashed_passwords.pl> to match the following (the only difference
is the C<connect> line):
#!/usr/bin/perl
$user->update;
}
-Run the C<set_hashed_passwords.pl> as per the "normal" flow of the
+Run the F<set_hashed_passwords.pl> as per the "normal" flow of the
tutorial:
$ perl -Ilib set_hashed_passwords.pl
=item *
-Open the C<myapp01_mysql.sql> in your editor and enter:
+Open the F<myapp01_mysql.sql> in your editor and enter:
--
-- Create a very simple database to hold book and author information
Create the C<.sql> file for the user/roles data:
-Open C<myapp02_mysql.sql> in your editor and enter:
+Open F<myapp02_mysql.sql> in your editor and enter:
--
-- Add users and roles tables, along with a many-to-many join table
Create the C<.sql> file for the hashed password data:
-Open C<myapp03_mysql.sql> in your editor and enter:
+Open F<myapp03_mysql.sql> in your editor and enter:
--
-- Convert passwords to SHA-1 hashes
projects / catagits/Catalyst-Manual.git / commitdiff