The 'Catalyst-Devel' distribution includes a variety of modules useful for
the development of Catalyst applications, but not required to run them.
This is intended to make it easier to deploy Catalyst apps. The runtime
parts of Catalyst are now known as 'Catalyst::Runtime'.

'Catalyst-Devel' includes the the Catalyst::Helper manpage system, which
autogenerates scripts and tests; the Module::Install::Catalyst manpage, a
the Module::Install manpage extension for Catalyst; and requirements for a
variety of development-related modules. The documentation remains with the
Catalyst::Runtime manpage.

Catalyst::Engine::PSGI is a Catalyst Engine that adapts Catalyst into the
PSGI gateway protocol.

The authentication plugin provides generic user support for Catalyst apps.
It is the basis for both authentication (checking the user is who they
claim to be), and authorization (allowing the user to do what the system
authorises them to do).

Using authentication is split into two parts. A Store is used to actually
store the user information, and can store any amount of data related to the
user. Credentials are used to verify users, using information from the
store, given data from the frontend. A Credential and a Store are paired to
form a 'Realm'. A Catalyst application using the authentication framework
must have at least one realm, and may have several.

To implement authentication in a Catalyst application you need to add this
module, and specify at least one realm in the configuration.

Authentication data can also be stored in a session, if the application is
using the the Catalyst::Plugin::Session manpage module.

*NOTE* in version 0.10 of this module, the interface to this module
changed. Please see the /COMPATIBILITY ROUTINES manpage for more
information.

This module will attempt to load find and load a configuration file of
various types. Currently it supports YAML, JSON, XML, INI and Perl formats.
Special configuration for a particular driver format can be stored in
'MyApp->config->{ 'Plugin::ConfigLoader' }->{ driver }'. For example, to
pass arguments to the Config::General manpage, use the following:

__PACKAGE__->config( 'Plugin::ConfigLoader' => {
driver => {
'General' => { -LowerCaseNames => 1 }
}
} );

See the Config::Any manpage's 'driver_args' parameter for more information.

To support the distinction between development and production environments,
this module will also attemp to load a local config (e.g. myapp_local.yaml)
which will override any duplicate settings. See /get_config_local_suffix
for details on how this is configured.

Supports mo/po files and Maketext classes under your application's I18N
namespace.

# MyApp/I18N/de.po
msgid "Hello Catalyst"
msgstr "Hallo Katalysator"

# MyApp/I18N/i_default.po
msgid "messages.hello.catalyst"
msgstr "Hello Catalyst - fallback translation"

# MyApp/I18N/de.pm
package MyApp::I18N::de;
use base 'MyApp::I18N';
our %Lexicon = ( 'Hello Catalyst' => 'Hallo Katalysator' );
1;

CONFIGURATION
You can override any parameter sent to the Locale::Maketext::Simple
manpage by specifying a 'maketext_options' hashref to the
'Plugin::I18N' config section. For example, the following configuration
will override the 'Decode' parameter which normally defaults to '1':

__PACKAGE__->config(
'Plugin::I18N' =>
maketext_options => {
Decode => 0
}
);

All languages fallback to MyApp::I18N which is mapped onto the
i-default language tag. If you use arbitrary message keys, use
i_default.po to translate into English, otherwise the message key
itself is returned.

EXTENDED METHODS
setup
METHODS
languages
Contains languages.

$c->languages(['de_DE']);
print join '', @{ $c->languages };

language
return selected locale in your locales list.

language_tag
return language tag for current locale. The most notable difference
from this method in comparison to 'language()' is typically that
languages and regions are joined with a dash and not an underscore.

$c->language(); # en_us
$c->language_tag(); # en-us

installed_languages
Returns a hash of { langtag => "descriptive name for language" }
based on language files in your application's I18N directory. The
descriptive name is based on I18N::LangTags::List information. If
the descriptive name is not available, will be undef.

loc
localize
Localize text.

print $c->localize( 'Welcome to Catalyst, [_1]', 'sri' );

The Session plugin is the base of two related parts of functionality
required for session management in web applications.

The first part, the State, is getting the browser to repeat back a session
key, so that the web application can identify the client and logically
string several requests together into a session.

The second part, the Store, deals with the actual storage of information
about the client. This data is stored so that the it may be revived for
every request made by the same client.

This plugin links the two pieces together.

In order for the Catalyst::Plugin::Session manpage to work the session ID
needs to be stored on the client, and the session data needs to be stored
on the server.

This plugin stores the session ID on the client using the cookie mechanism.

This the Catalyst::Plugin::Session manpage storage module saves session
data in your database via the DBIx::Class manpage. It's actually just a
wrapper around the Catalyst::Plugin::Session::Store::Delegate manpage; if
you need complete control over how your sessions are stored, you probably
want to use that instead.

This store plugins makes delegating session storage to a first class object
model easy.

'Catalyst::Plugin::Session::Store::File' is an easy to use storage plugin
for Catalyst that uses an simple file to act as a shared memory
interprocess cache. It is based on 'Cache::FileCache'.

This plugin will enhance the standard Catalyst debug screen by including a
stack trace of your appliation up to the point where the error occurred.
Each stack frame is displayed along with the package name, line number,
file name, and code context surrounding the line number.

This plugin is only active in -Debug mode by default, but can be enabled by
setting the 'enable' config option.

The Static::Simple plugin is designed to make serving static content in
your application during development quick and easy, without requiring a
single line of code from you.

This plugin detects static files by looking at the file extension in the
URL (such as *.css* or *.png* or *.js*). The plugin uses the lightweight
the MIME::Types manpage module to map file extensions to IANA-registered
MIME types, and will serve your static files with the correct MIME type
directly to the browser, without being processed through Catalyst.

Note that actions mapped to paths using periods (.) will still operate
properly.

If the plugin can not find the file, the request is dispatched to your
application instead. This means you are responsible for generating a '404'
error if your applicaton can not process the request:

# handled by static::simple, not dispatched to your application
/images/exists.png

# static::simple will not find the file and let your application
# handle the request. You are responsible for generating a file
# or returning a 404 error
/images/does_not_exist.png

Though Static::Simple is designed to work out-of-the-box, you can tweak the
operation by adding various configuration options. In a production
environment, you will probably want to use your webserver to deliver static
content; for an example see the USING WITH APACHE manpage, below.

sorry, no description found

This is the Catalyst view class for the Template. Your application should
defined a view class which is a subclass of this module. Throughout this
manual it will be assumed that your application is named _MyApp_ and you
are creating a TT view named _Web_; these names are placeholders and should
always be replaced with whatever name you've chosen for your application
and your view.

This module/script gets the CDDB info for an audio cd. You need LINUX,
SUNOS or *BSD, a cdrom drive and an active internet connection in order
to do that.