=over
-=item
+=item *
INCLUDE_PATH defines the directories that Template Toolkit should search
for the template files.
-=item
+=item *
PRE_PROCESS is used to process configuration options which are common to
every template file.
-=item
+=item *
WRAPPER is a file which is processed with each template, usually used to
easily provide a common header and footer for every page.
of the page around your template for you.
-=head3 $c->stash
+=head3 C<< $c->stash >>
Of course, having the template system include the header and footer for
you isn't all that we want our templates to do. We need to be able to
and allows you to truly keep your presentation logic separate from the
rest of your application.
-=head3 $c->uri_for()
+=head3 C<< $c->uri_for() >>
One of my favorite things about Catalyst is the ability to move an
application around without having to worry that everything is going to
the application to be at http://www.mydomain.com/Tools/Calendar, then
all of those links will suddenly break.
-That's where $c->uri_for() comes in. This function will merge its
+That's where C<< $c->uri_for() >> comes in. This function will merge its
parameters with either the base location for the app, or its current
namespace. Let's take a look at a couple of examples.
The first parameter does NOT have a forward slash, and so it will be
relative to the current namespace. If the application is installed at
http://www.domain.com/Calendar. and if the template is called from
-MyApp::Controller::Display, then the link would become
+C<MyApp::Controller::Display>, then the link would become
http://www.domain.com/Calendar/Display/2005/10/24.
If you want to link to a parent uri of your current namespace you can
framework built specifically for automating cloud computing deployments. A
Cookbooks demonstrating how to deploy a Catalyst application using Chef is
available at L<http://community.opscode.com/cookbooks/catalyst> and
-L<http://github.com/melezhik/cookbooks/wiki/Catalyst-cookbook-intro>.
+L<https://github.com/melezhik/cookbooks/wiki/Catalyst-cookbook-intro>.
=head1 AUTHORS
written to help you understand the possibilities, current practices
and their consequences.
-Please read the L<BEST PRACTICES> section before deciding on a design,
+Please read the L</BEST PRACTICES> section before deciding on a design,
especially if you plan to release your code to CPAN. The Catalyst
developer and user communities, which B<you are part of>, will benefit
most if we all work together and coordinate.
accessor.
The C<config> accessor always only contains the original class configuration
-and you B<MUST NEVER> call $self->config to get your component configuration,
+and you B<MUST NEVER> call C<< $self->config >> to get your component configuration,
as the data there is likely to be a subset of the correct config.
For example:
C<finalize_*> stages, you won't get around a plugin.
Note, if you just want to hook into such a stage, and run code before,
-or after it, then it is recommended that you use L<Moose>s method modifiers
+or after it, then it is recommended that you use L<Moose>'s method modifiers
to do this.
Another valid target for a plugin architecture are things that
be C<TT>, and the second that it should be a Template Toolkit view.)
This gives us a process() method and we can now just do
-$c->forward('MyApp::View::TT') to render our templates. The base class
+C<< $c->forward('MyApp::View::TT') >> to render our templates. The base class
makes process() implicit, so we don't have to say
C<< $c->forward(qw/MyApp::View::TT process/) >>.
=head3 ACCEPT_CONTEXT
-Whenever you call $c->component("Foo") you get back an object - the
+Whenever you call C<< $c->component("Foo") >> you get back an object - the
instance of the model. If the component supports the C<ACCEPT_CONTEXT>
method instead of returning the model itself, the return value of C<<
$model->ACCEPT_CONTEXT( $c ) >> will be used.
Note that we still want the Catalyst models to be a thin wrapper
around classes that will work independently of the Catalyst
application to promote reusability of code. Here we might just want
-to grab the $c->model('DB')->schema so as to get the connection
+to grab the C<< $c->model('DB')->schema >> so as to get the connection
information from the Catalyst application's configuration for example.
The life time of this value is B<per usage>, and not per request. To
C<< $c->welcome_message >> is a special method that returns the welcome
message that you saw in your browser.
-The ":Path :Args(0)" after the method name are attributes which
+The "C<:Path :Args(0)>" after the method name are attributes which
determine which URLs will be dispatched to this method. (You might see
":Private" if you are using an older version of Catalyst, but using that
with "default" or "index" is currently deprecated. If so, you should
methods. There is a lot of flexibility in specifying which URLs to
match. This particular method will match all URLs, because it doesn't
specify the path (nothing comes after "Path"), but will only accept a
-URL without any args because of the ":Args(0)".
+URL without any args because of the "C<:Args(0)>".
The default is to map URLs to controller names, and because of the way
that Perl handles namespaces through package names, it is simple to
=item *
Although it is beyond the scope of this tutorial, you may wish to use a
-JavaScript or AJAX tool such as jQuery (L<http://www.jquery.com>) or
+JavaScript or AJAX tool such as jQuery (L<https://www.jquery.com>) or
Dojo (L<http://www.dojotoolkit.org>).
=back
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 F<root/src/books/list.tt2> and replace the
-"empty" table cell "<td></td>" with the following:
+"empty" table cell "C<< <td></td> >>" with the following:
...
<td>
database by using a salted SHA-1 hash. If you are concerned about
cleartext passwords between the browser and your application, consider
using SSL/TLS, made easy with modules such as
-L<Catalyst::Plugin:RequireSSL> and L<Catalyst::ActionRole::RequireSSL>.
+L<Catalyst::Plugin::RequireSSL> and L<Catalyst::ActionRole::RequireSSL>.
=head2 Re-Run the DBIC::Schema Model Helper to Include DBIx::Class::PassphraseColumn
...
Although the sample above only shows the C<content> div, leave the rest
-of the file intact -- the only change we made to replace "||
-c.request.params.status_msg" with "c.flash.status_msg" in the
+of the file intact -- the only change we made to replace "C<||
+c.request.params.status_msg>" with "C<c.flash.status_msg>" in the
C<< <span class="message"> >> line.
- HTMLEscape
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.
The main changes are:
=item *
-":0,$s/^ "
+C<":0,$s/^ ">
Removes four leading spaces from the entire file (from the first line,
C<0>, to the last line, C<$>).
=item *
-"%s/^ "
+C<"%s/^ ">
A shortcut for the previous item (C<%> specifies the entire file; so
this removes four leading spaces from every line).
=item *
-":.,44s/^ "
+C<":.,44s/^ ">
Removes four leading space from the current line through line 44
(obviously adjust the C<44> to the appropriate value in your example).
projects / catagits/Catalyst-Manual.git / commitdiff