1Catalyst(3)           User Contributed Perl Documentation          Catalyst(3)
2
3
4

NAME

6       Catalyst - The Elegant MVC Web Application Framework
7

SYNOPSIS

9       See the Catalyst::Manual distribution for comprehensive documentation
10       and tutorials.
11
12           # Install Catalyst::Devel for helpers and other development tools
13           # use the helper to create a new application
14           catalyst.pl MyApp
15
16           # add models, views, controllers
17           script/myapp_create.pl model MyDatabase DBIC::Schema create=static dbi:SQLite:/path/to/db
18           script/myapp_create.pl view MyTemplate TT
19           script/myapp_create.pl controller Search
20
21           # built in testserver -- use -r to restart automatically on changes
22           # --help to see all available options
23           script/myapp_server.pl
24
25           # command line testing interface
26           script/myapp_test.pl /yada
27
28           ### in lib/MyApp.pm
29           use Catalyst qw/-Debug/; # include plugins here as well
30
31           ### In lib/MyApp/Controller/Root.pm (autocreated)
32           sub foo : Chained('/') Args() { # called for /foo, /foo/1, /foo/1/2, etc.
33               my ( $self, $c, @args ) = @_; # args are qw/1 2/ for /foo/1/2
34               $c->stash->{template} = 'foo.tt'; # set the template
35               # lookup something from db -- stash vars are passed to TT
36               $c->stash->{data} =
37                 $c->model('Database::Foo')->search( { country => $args[0] } );
38               if ( $c->req->params->{bar} ) { # access GET or POST parameters
39                   $c->forward( 'bar' ); # process another action
40                   # do something else after forward returns
41               }
42           }
43
44           # The foo.tt TT template can use the stash data from the database
45           [% WHILE (item = data.next) %]
46               [% item.foo %]
47           [% END %]
48
49           # called for /bar/of/soap, /bar/of/soap/10, etc.
50           sub bar : Chained('/') PathPart('/bar/of/soap') Args() { ... }
51
52           # called after all actions are finished
53           sub end : Action {
54               my ( $self, $c ) = @_;
55               if ( scalar @{ $c->error } ) { ... } # handle errors
56               return if $c->res->body; # already have a response
57               $c->forward( 'MyApp::View::TT' ); # render template
58           }
59
60       See Catalyst::Manual::Intro for additional information.
61

DESCRIPTION

63       Catalyst is a modern framework for making web applications without the
64       pain usually associated with this process. This document is a reference
65       to the main Catalyst application. If you are a new user, we suggest you
66       start with Catalyst::Manual::Tutorial or Catalyst::Manual::Intro.
67
68       See Catalyst::Manual for more documentation.
69
70       Catalyst plugins can be loaded by naming them as arguments to the "use
71       Catalyst" statement. Omit the "Catalyst::Plugin::" prefix from the
72       plugin name, i.e., "Catalyst::Plugin::My::Module" becomes "My::Module".
73
74           use Catalyst qw/My::Module/;
75
76       If your plugin starts with a name other than "Catalyst::Plugin::", you
77       can fully qualify the name by using a unary plus:
78
79           use Catalyst qw/
80               My::Module
81               +Fully::Qualified::Plugin::Name
82           /;
83
84       Special flags like "-Debug" can also be specified as arguments when
85       Catalyst is loaded:
86
87           use Catalyst qw/-Debug My::Module/;
88
89       The position of plugins and flags in the chain is important, because
90       they are loaded in the order in which they appear.
91
92       The following flags are supported:
93
94   -Debug
95       Enables debug output. You can also force this setting from the system
96       environment with CATALYST_DEBUG or <MYAPP>_DEBUG. The environment
97       settings override the application, with <MYAPP>_DEBUG having the
98       highest priority.
99
100       This sets the log level to 'debug' and enables full debug output on the
101       error screen. If you only want the latter, see $c->debug.
102
103   -Home
104       Forces Catalyst to use a specific home directory, e.g.:
105
106           use Catalyst qw[-Home=/usr/mst];
107
108       This can also be done in the shell environment by setting either the
109       "CATALYST_HOME" environment variable or "MYAPP_HOME"; where "MYAPP" is
110       replaced with the uppercased name of your application, any "::" in the
111       name will be replaced with underscores, e.g. MyApp::Web should use
112       MYAPP_WEB_HOME. If both variables are set, the MYAPP_HOME one will be
113       used.
114
115       If none of these are set, Catalyst will attempt to automatically detect
116       the home directory. If you are working in a development environment,
117       Catalyst will try and find the directory containing either Makefile.PL,
118       Build.PL, dist.ini, or cpanfile. If the application has been installed
119       into the system (i.e. you have done "make install"), then Catalyst will
120       use the path to your application module, without the .pm extension
121       (e.g., /foo/MyApp if your application was installed at /foo/MyApp.pm)
122
123   -Log
124           use Catalyst '-Log=warn,fatal,error';
125
126       Specifies a comma-delimited list of log levels.
127
128   -Stats
129       Enables statistics collection and reporting.
130
131          use Catalyst qw/-Stats=1/;
132
133       You can also force this setting from the system environment with
134       CATALYST_STATS or <MYAPP>_STATS. The environment settings override the
135       application, with <MYAPP>_STATS having the highest priority.
136
137       Stats are also enabled if debugging  is enabled.
138

METHODS

140   INFORMATION ABOUT THE CURRENT REQUEST
141   $c->action
142       Returns a Catalyst::Action object for the current action, which
143       stringifies to the action name. See Catalyst::Action.
144
145   $c->namespace
146       Returns the namespace of the current action, i.e., the URI prefix
147       corresponding to the controller of the current action. For example:
148
149           # in Controller::Foo::Bar
150           $c->namespace; # returns 'foo/bar';
151
152   $c->request
153   $c->req
154       Returns the current Catalyst::Request object, giving access to
155       information about the current client request (including parameters,
156       cookies, HTTP headers, etc.). See Catalyst::Request.
157
158       There is a predicate method "has_request" that returns true if the
159       request object has been created.  This is something you might need to
160       check if you are writing plugins that run before a request is
161       finalized.
162
163   REQUEST FLOW HANDLING
164   $c->forward( $action [, \@arguments ] )
165   $c->forward( $class, $method, [, \@arguments ] )
166       This is one way of calling another action (method) in the same or a
167       different controller. You can also use "$self->my_method($c, @args)" in
168       the same controller or "$c->controller('MyController')->my_method($c,
169       @args)" in a different controller.  The main difference is that
170       'forward' uses some of the Catalyst request cycle overhead, including
171       debugging, which may be useful to you. On the other hand, there are
172       some complications to using 'forward', restrictions on values returned
173       from 'forward', and it may not handle errors as you prefer.  Whether
174       you use 'forward' or not is up to you; it is not considered superior to
175       the other ways to call a method.
176
177       'forward' calls  another action, by its private name. If you give a
178       class name but no method, "process()" is called. You may also
179       optionally pass arguments in an arrayref. The action will receive the
180       arguments in @_ and "$c->req->args". Upon returning from the function,
181       "$c->req->args" will be restored to the previous values.
182
183       Any data "return"ed from the action forwarded to, will be returned by
184       the call to forward.
185
186           my $foodata = $c->forward('/foo');
187           $c->forward('index');
188           $c->forward(qw/Model::DBIC::Foo do_stuff/);
189           $c->forward('View::TT');
190
191       Note that forward implies an "eval { }" around the call (actually
192       execute does), thus rendering all exceptions thrown by the called
193       action non-fatal and pushing them onto $c->error instead. If you want
194       "die" to propagate you need to do something like:
195
196           $c->forward('foo');
197           die join "\n", @{ $c->error } if @{ $c->error };
198
199       Or make sure to always return true values from your actions and write
200       your code like this:
201
202           $c->forward('foo') || return;
203
204       Another note is that "$c->forward" always returns a scalar because it
205       actually returns $c->state which operates in a scalar context.  Thus,
206       something like:
207
208           return @array;
209
210       in an action that is forwarded to is going to return a scalar, i.e. how
211       many items are in that array, which is probably not what you want.  If
212       you need to return an array then return a reference to it, or stash it
213       like so:
214
215           $c->stash->{array} = \@array;
216
217       and access it from the stash.
218
219       Keep in mind that the "end" method used is that of the caller action.
220       So a "$c->detach" inside a forwarded action would run the "end" method
221       from the original action requested.
222
223   $c->detach( $action [, \@arguments ] )
224   $c->detach( $class, $method, [, \@arguments ] )
225   $c->detach()
226       The same as forward, but doesn't return to the previous action when
227       processing is finished.
228
229       When called with no arguments it escapes the processing chain entirely.
230
231   $c->visit( $action [, \@arguments ] )
232   $c->visit( $action [, \@captures, \@arguments ] )
233   $c->visit( $class, $method, [, \@arguments ] )
234   $c->visit( $class, $method, [, \@captures, \@arguments ] )
235       Almost the same as forward, but does a full dispatch, instead of just
236       calling the new $action / "$class->$method". This means that "begin",
237       "auto" and the method you go to are called, just like a new request.
238
239       In addition both "$c->action" and "$c->namespace" are localized.  This
240       means, for example, that "$c->action" methods such as name, class and
241       reverse return information for the visited action when they are invoked
242       within the visited action.  This is different from the behavior of
243       forward, which continues to use the $c->action object from the caller
244       action even when invoked from the called action.
245
246       "$c->stash" is kept unchanged.
247
248       In effect, visit allows you to "wrap" another action, just as it would
249       have been called by dispatching from a URL, while the analogous go
250       allows you to transfer control to another action as if it had been
251       reached directly from a URL.
252
253   $c->go( $action [, \@arguments ] )
254   $c->go( $action [, \@captures, \@arguments ] )
255   $c->go( $class, $method, [, \@arguments ] )
256   $c->go( $class, $method, [, \@captures, \@arguments ] )
257       The relationship between "go" and visit is the same as the relationship
258       between forward and detach. Like "$c->visit", "$c->go" will perform a
259       full dispatch on the specified action or method, with localized
260       "$c->action" and "$c->namespace". Like "detach", "go" escapes the
261       processing of the current request chain on completion, and does not
262       return to its caller.
263
264       @arguments are arguments to the final destination of $action. @captures
265       are arguments to the intermediate steps, if any, on the way to the
266       final sub of $action.
267
268   $c->response
269   $c->res
270       Returns the current Catalyst::Response object, see there for details.
271
272       There is a predicate method "has_response" that returns true if the
273       request object has been created.  This is something you might need to
274       check if you are writing plugins that run before a request is
275       finalized.
276
277   $c->stash
278       Returns a hashref to the stash, which may be used to store data and
279       pass it between components during a request. You can also set hash keys
280       by passing arguments. The stash is automatically sent to the view. The
281       stash is cleared at the end of a request; it cannot be used for
282       persistent storage (for this you must use a session; see
283       Catalyst::Plugin::Session for a complete system integrated with
284       Catalyst).
285
286           $c->stash->{foo} = $bar;
287           $c->stash( { moose => 'majestic', qux => 0 } );
288           $c->stash( bar => 1, gorch => 2 ); # equivalent to passing a hashref
289
290           # stash is automatically passed to the view for use in a template
291           $c->forward( 'MyApp::View::TT' );
292
293       The stash hash is currently stored in the PSGI $env and is managed by
294       Catalyst::Middleware::Stash.  Since it's part of the $env items in the
295       stash can be accessed in sub applications mounted under your main
296       Catalyst application.  For example if you delegate the response of an
297       action to another Catalyst application, that sub application will have
298       access to all the stash keys of the main one, and if can of course add
299       more keys of its own.  However those new keys will not 'bubble' back up
300       to the main application.
301
302       For more information the best thing to do is to review the test case:
303       t/middleware-stash.t in the distribution /t directory.
304
305   $c->error
306   $c->error($error, ...)
307   $c->error($arrayref)
308       Returns an arrayref containing error messages.  If Catalyst encounters
309       an error while processing a request, it stores the error in $c->error.
310       This method should only be used to store fatal error messages.
311
312           my @error = @{ $c->error };
313
314       Add a new error.
315
316           $c->error('Something bad happened');
317
318       Calling this will always return an arrayref (if there are no errors it
319       will be an empty arrayref.
320
321   $c->state
322       Contains the return value of the last executed action.  Note that <<
323       $c->state >> operates in a scalar context which means that all values
324       it returns are scalar.
325
326       Please note that if an action throws an exception, the value of state
327       should no longer be considered the return if the last action.  It is
328       generally going to be 0, which indicates an error state.  Examine
329       $c->error for error details.
330
331   $c->clear_errors
332       Clear errors.  You probably don't want to clear the errors unless you
333       are implementing a custom error screen.
334
335       This is equivalent to running
336
337           $c->error(0);
338
339   $c->has_errors
340       Returns true if you have errors
341
342   $c->last_error
343       Returns the most recent error in the stack (the one most recently
344       added...)  or nothing if there are no errors.  This does not modify the
345       contents of the error stack.
346
347   shift_errors
348       shifts the most recently added error off the error stack and returns
349       it.  Returns nothing if there are no more errors.
350
351   pop_errors
352       pops the most recently added error off the error stack and returns it.
353       Returns nothing if there are no more errors.
354
355   COMPONENT ACCESSORS
356   $c->controller($name)
357       Gets a Catalyst::Controller instance by name.
358
359           $c->controller('Foo')->do_stuff;
360
361       If the name is omitted, will return the controller for the dispatched
362       action.
363
364       If you want to search for controllers, pass in a regexp as the
365       argument.
366
367           # find all controllers that start with Foo
368           my @foo_controllers = $c->controller(qr{^Foo});
369
370   $c->model($name)
371       Gets a Catalyst::Model instance by name.
372
373           $c->model('Foo')->do_stuff;
374
375       Any extra arguments are directly passed to ACCEPT_CONTEXT, if the model
376       defines ACCEPT_CONTEXT.  If it does not, the args are discarded.
377
378       If the name is omitted, it will look for
379        - a model object in $c->stash->{current_model_instance}, then
380        - a model name in $c->stash->{current_model}, then
381        - a config setting 'default_model', or
382        - check if there is only one model, and return it if that's the case.
383
384       If you want to search for models, pass in a regexp as the argument.
385
386           # find all models that start with Foo
387           my @foo_models = $c->model(qr{^Foo});
388
389   $c->view($name)
390       Gets a Catalyst::View instance by name.
391
392           $c->view('Foo')->do_stuff;
393
394       Any extra arguments are directly passed to ACCEPT_CONTEXT.
395
396       If the name is omitted, it will look for
397        - a view object in $c->stash->{current_view_instance}, then
398        - a view name in $c->stash->{current_view}, then
399        - a config setting 'default_view', or
400        - check if there is only one view, and return it if that's the case.
401
402       If you want to search for views, pass in a regexp as the argument.
403
404           # find all views that start with Foo
405           my @foo_views = $c->view(qr{^Foo});
406
407   $c->controllers
408       Returns the available names which can be passed to $c->controller
409
410   $c->models
411       Returns the available names which can be passed to $c->model
412
413   $c->views
414       Returns the available names which can be passed to $c->view
415
416   $c->comp($name)
417   $c->component($name)
418       Gets a component object by name. This method is not recommended, unless
419       you want to get a specific component by full class. "$c->controller",
420       "$c->model", and "$c->view" should be used instead.
421
422       If $name is a regexp, a list of components matched against the full
423       component name will be returned.
424
425       If Catalyst can't find a component by name, it will fallback to regex
426       matching by default. To disable this behaviour set
427       disable_component_resolution_regex_fallback to a true value.
428
429           __PACKAGE__->config( disable_component_resolution_regex_fallback => 1 );
430
431   CLASS DATA AND HELPER CLASSES
432   $c->config
433       Returns or takes a hashref containing the application's configuration.
434
435           __PACKAGE__->config( { db => 'dsn:SQLite:foo.db' } );
436
437       You can also use a "YAML", "XML" or Config::General config file like
438       "myapp.conf" in your applications home directory. See
439       Catalyst::Plugin::ConfigLoader.
440
441       Cascading configuration
442
443       The config method is present on all Catalyst components, and
444       configuration will be merged when an application is started.
445       Configuration loaded with Catalyst::Plugin::ConfigLoader takes
446       precedence over other configuration, followed by configuration in your
447       top level "MyApp" class. These two configurations are merged, and then
448       configuration data whose hash key matches a component name is merged
449       with configuration for that component.
450
451       The configuration for a component is then passed to the "new" method
452       when a component is constructed.
453
454       For example:
455
456           MyApp->config({ 'Model::Foo' => { bar => 'baz', overrides => 'me' } });
457           MyApp::Model::Foo->config({ quux => 'frob', overrides => 'this' });
458
459       will mean that "MyApp::Model::Foo" receives the following data when
460       constructed:
461
462           MyApp::Model::Foo->new({
463               bar => 'baz',
464               quux => 'frob',
465               overrides => 'me',
466           });
467
468       It's common practice to use a Moose attribute on the receiving
469       component to access the config value.
470
471           package MyApp::Model::Foo;
472
473           use Moose;
474
475           # this attr will receive 'baz' at construction time
476           has 'bar' => (
477               is  => 'rw',
478               isa => 'Str',
479           );
480
481       You can then get the value 'baz' by calling $c->model('Foo')->bar (or
482       $self->bar inside code in the model).
483
484       NOTE: you MUST NOT call "$self->config" or "__PACKAGE__->config" as a
485       way of reading config within your code, as this will not give you the
486       correctly merged config back. You MUST take the config values supplied
487       to the constructor and use those instead.
488
489   $c->log
490       Returns the logging object instance. Unless it is already set, Catalyst
491       sets this up with a Catalyst::Log object. To use your own log class,
492       set the logger with the "__PACKAGE__->log" method prior to calling
493       "__PACKAGE__->setup".
494
495        __PACKAGE__->log( MyLogger->new );
496        __PACKAGE__->setup;
497
498       And later:
499
500           $c->log->info( 'Now logging with my own logger!' );
501
502       Your log class should implement the methods described in Catalyst::Log.
503
504   has_encoding
505       Returned True if there's a valid encoding
506
507   clear_encoding
508       Clears the encoding for the current context
509
510   encoding
511       Sets or gets the application encoding.  Setting encoding takes either
512       an Encoding object or a string that we try to resolve via
513       Encode::find_encoding.
514
515       You would expect to get the encoding object back if you attempt to set
516       it.  If there is a failure you will get undef returned and an error
517       message in the log.
518
519   $c->debug
520       Returns 1 if debug mode is enabled, 0 otherwise.
521
522       You can enable debug mode in several ways:
523
524       By calling myapp_server.pl with the -d flag
525       With the environment variables MYAPP_DEBUG, or CATALYST_DEBUG
526       The -Debug option in your MyApp.pm
527       By declaring "sub debug { 1 }" in your MyApp.pm.
528
529       The first three also set the log level to 'debug'.
530
531       Calling "$c->debug(1)" has no effect.
532
533   $c->dispatcher
534       Returns the dispatcher instance. See Catalyst::Dispatcher.
535
536   $c->engine
537       Returns the engine instance. See Catalyst::Engine.
538
539   UTILITY METHODS
540   $c->path_to(@path)
541       Merges @path with "$c->config->{home}" and returns a Path::Class::Dir
542       object. Note you can usually use this object as a filename, but
543       sometimes you will have to explicitly stringify it yourself by calling
544       the "->stringify" method.
545
546       For example:
547
548           $c->path_to( 'db', 'sqlite.db' );
549
550   MyApp->setup
551       Initializes the dispatcher and engine, loads any plugins, and loads the
552       model, view, and controller components. You may also specify an array
553       of plugins to load here, if you choose to not load them in the "use
554       Catalyst" line.
555
556           MyApp->setup;
557           MyApp->setup( qw/-Debug/ );
558
559       Note: You should not wrap this method with method modifiers or bad
560       things will happen - wrap the "setup_finalize" method instead.
561
562       Note: You can create a custom setup stage that will execute when the
563       application is starting.  Use this to customize setup.
564
565           MyApp->setup(-Custom=value);
566
567           sub setup_custom {
568             my ($class, $value) = @_;
569           }
570
571       Can be handy if you want to hook into the setup phase.
572
573   $app->setup_finalize
574       A hook to attach modifiers to. This method does not do anything except
575       set the "setup_finished" accessor.
576
577       Applying method modifiers to the "setup" method doesn't work, because
578       of quirky things done for plugin setup.
579
580       Example:
581
582           after setup_finalize => sub {
583               my $app = shift;
584
585               ## do stuff here..
586           };
587
588   $c->uri_for( $path?, @args?, \%query_values?, \$fragment? )
589   $c->uri_for( $action, \@captures?, @args?, \%query_values?, \$fragment? )
590   $c->uri_for( $action, [@captures, @args], \%query_values?, \$fragment? )
591       Constructs an absolute URI object based on the application root, the
592       provided path, and the additional arguments and query parameters
593       provided.  When used as a string, provides a textual URI.  If you need
594       more flexibility than this (i.e. the option to provide relative URIs
595       etc.) see Catalyst::Plugin::SmartURI.
596
597       If no arguments are provided, the URI for the current action is
598       returned.  To return the current action and also provide @args, use
599       "$c->uri_for( $c->action, @args )".
600
601       If the first argument is a string, it is taken as a public URI path
602       relative to "$c->namespace" (if it doesn't begin with a forward slash)
603       or relative to the application root (if it does). It is then merged
604       with "$c->request->base"; any @args are appended as additional path
605       components; and any %query_values are appended as "?foo=bar"
606       parameters.
607
608       NOTE If you are using this 'stringy' first argument, we skip encoding
609       and allow you to declare something like:
610
611           $c->uri_for('/foo/bar#baz')
612
613       Where 'baz' is a URI fragment.  We consider this first argument string
614       to be 'expert' mode where you are expected to create a valid URL and we
615       for the most part just pass it through without a lot of internal effort
616       to escape and encode.
617
618       If the first argument is a Catalyst::Action it represents an action
619       which will have its path resolved using
620       "$c->dispatcher->uri_for_action". The optional "\@captures" argument
621       (an arrayref) allows passing the captured variables that are needed to
622       fill in the paths of Chained and Regex actions; once the path is
623       resolved, "uri_for" continues as though a path was provided, appending
624       any arguments or parameters and creating an absolute URI.
625
626       The captures for the current request can be found in
627       "$c->request->captures", and actions can be resolved using
628       "Catalyst::Controller->action_for($name)". If you have a private action
629       path, use "$c->uri_for_action" instead.
630
631         # Equivalent to $c->req->uri
632         $c->uri_for($c->action, $c->req->captures,
633             @{ $c->req->args }, $c->req->params);
634
635         # For the Foo action in the Bar controller
636         $c->uri_for($c->controller('Bar')->action_for('Foo'));
637
638         # Path to a static resource
639         $c->uri_for('/static/images/logo.png');
640
641       In general the scheme of the generated URI object will follow the
642       incoming request however if your targeted action or action chain has
643       the Scheme attribute it will use that instead.
644
645       Also, if the targeted Action or Action chain declares Args/CaptureArgs
646       that have type constraints, we will require that your proposed URL
647       verify on those declared constraints.
648
649   $c->uri_for_action( $path, \@captures_and_args?, @args?, \%query_values? )
650   $c->uri_for_action( $action, \@captures_and_args?, @args?, \%query_values?
651       )
652       $path
653           A private path to the Catalyst action you want to create a URI for.
654
655           This is a shortcut for calling
656           "$c->dispatcher->get_action_by_path($path)" and passing the
657           resulting $action and the remaining arguments to "$c->uri_for".
658
659           You can also pass in a Catalyst::Action object, in which case it is
660           passed to "$c->uri_for".
661
662           Note that although the path looks like a URI that dispatches to the
663           wanted action, it is not a URI, but an internal path to that
664           action.
665
666           For example, if the action looks like:
667
668            package MyApp::Controller::Users;
669
670            sub lst : Path('the-list') {}
671
672           You can use:
673
674            $c->uri_for_action('/users/lst')
675
676           and it will create the URI /users/the-list.
677
678       \@captures_and_args?
679           Optional array reference of Captures (i.e. "CaptureArgs" or
680           "$c->req->captures") and arguments to the request. Usually used
681           with Catalyst::DispatchType::Chained to interpolate all the
682           parameters in the URI.
683
684       @args?
685           Optional list of extra arguments - can be supplied in the
686           "\@captures_and_args?" array ref, or here - whichever is easier for
687           your code.
688
689           Your action can have zero, a fixed or a variable number of args
690           (e.g.  Args(1) for a fixed number or "Args()" for a variable
691           number)..
692
693       \%query_values?
694           Optional array reference of query parameters to append. E.g.
695
696             { foo => 'bar' }
697
698           will generate
699
700             /rest/of/your/uri?foo=bar
701
702   $c->welcome_message
703       Returns the Catalyst welcome HTML page.
704
705   run_options
706       Contains a hash of options passed from the application script,
707       including the original ARGV the script received, the processed values
708       from that ARGV and any extra arguments to the script which were not
709       processed.
710
711       This can be used to add custom options to your application's scripts
712       and setup your application differently depending on the values of these
713       options.
714

INTERNAL METHODS

716       These methods are not meant to be used by end users.
717
718   $c->components
719       Returns a hash of components.
720
721   $c->context_class
722       Returns or sets the context class.
723
724   $c->counter
725       Returns a hashref containing coderefs and execution counts (needed for
726       deep recursion detection).
727
728   $c->depth
729       Returns the number of actions on the current internal execution stack.
730
731   $c->dispatch
732       Dispatches a request to actions.
733
734   $c->dispatcher_class
735       Returns or sets the dispatcher class.
736
737   $c->dump_these
738       Returns a list of 2-element array references (name, structure) pairs
739       that will be dumped on the error page in debug mode.
740
741   $c->engine_class
742       Returns or sets the engine class.
743
744   $c->execute( $class, $coderef )
745       Execute a coderef in given class and catch exceptions. Errors are
746       available via $c->error.
747
748   $c->finalize
749       Finalizes the request.
750
751   $c->log_stats
752       Logs statistics.
753
754   $c->finalize_body
755       Finalizes body.
756
757   $c->finalize_cookies
758       Finalizes cookies.
759
760   $c->finalize_error
761       Finalizes error.  If there is only one error in "error" and it is an
762       object that does "as_psgi" or "code" we rethrow the error and presume
763       it caught by middleware up the ladder.  Otherwise we return the
764       debugging error page (in debug mode) or we return the default error
765       page (production mode).
766
767   $c->finalize_headers
768       Finalizes headers.
769
770   $c->finalize_encoding
771       Make sure your body is encoded properly IF you set an encoding.  By
772       default the encoding is UTF-8 but you can disable it by explicitly
773       setting the encoding configuration value to undef.
774
775       We can only encode when the body is a scalar.  Methods for encoding via
776       the streaming interfaces (such as "write" and "write_fh" on
777       Catalyst::Response are available).
778
779       See "ENCODING".
780
781   $c->finalize_output
782       An alias for finalize_body.
783
784   $c->finalize_read
785       Finalizes the input after reading is complete.
786
787   $c->finalize_uploads
788       Finalizes uploads. Cleans up any temporary files.
789
790   $c->get_action( $action, $namespace )
791       Gets an action in a given namespace.
792
793   $c->get_actions( $action, $namespace )
794       Gets all actions of a given name in a namespace and all parent
795       namespaces.
796
797   $app->handle_request( @arguments )
798       Called to handle each HTTP request.
799
800   $class->prepare( @arguments )
801       Creates a Catalyst context from an engine-specific request (Apache,
802       CGI, etc.).
803
804   $c->prepare_action
805       Prepares action. See Catalyst::Dispatcher.
806
807   $c->prepare_body
808       Prepares message body.
809
810   $c->prepare_body_chunk( $chunk )
811       Prepares a chunk of data before sending it to HTTP::Body.
812
813       See Catalyst::Engine.
814
815   $c->prepare_body_parameters
816       Prepares body parameters.
817
818   $c->prepare_connection
819       Prepares connection.
820
821   $c->prepare_cookies
822       Prepares cookies by ensuring that the attribute on the request object
823       has been built.
824
825   $c->prepare_headers
826       Prepares request headers by ensuring that the attribute on the request
827       object has been built.
828
829   $c->prepare_parameters
830       Prepares parameters.
831
832   $c->prepare_path
833       Prepares path and base.
834
835   $c->prepare_query_parameters
836       Prepares query parameters.
837
838   $c->log_request
839       Writes information about the request to the debug logs.  This includes:
840
841       •   Request method, path, and remote IP address
842
843       •   Query keywords (see "query_keywords" in Catalyst::Request)
844
845       •   Request parameters
846
847       •   File uploads
848
849   $c->log_response
850       Writes information about the response to the debug logs by calling
851       "$c->log_response_status_line" and "$c->log_response_headers".
852
853   $c->log_response_status_line($response)
854       Writes one line of information about the response to the debug logs.
855       This includes:
856
857       •   Response status code
858
859       •   Content-Type header (if present)
860
861       •   Content-Length header (if present)
862
863   $c->log_response_headers($headers);
864       Hook method which can be wrapped by plugins to log the response
865       headers.  No-op in the default implementation.
866
867   $c->log_request_parameters( query => {}, body => {} )
868       Logs request parameters to debug logs
869
870   $c->log_request_uploads
871       Logs file uploads included in the request to the debug logs.  The
872       parameter name, filename, file type, and file size are all included in
873       the debug logs.
874
875   $c->log_request_headers($headers);
876       Hook method which can be wrapped by plugins to log the request headers.
877       No-op in the default implementation.
878
879   $c->log_headers($type => $headers)
880       Logs HTTP::Headers (either request or response) to the debug logs.
881
882   $c->prepare_read
883       Prepares the input for reading.
884
885   $c->prepare_request
886       Prepares the engine request.
887
888   $c->prepare_uploads
889       Prepares uploads.
890
891   $c->prepare_write
892       Prepares the output for writing.
893
894   $c->request_class
895       Returns or sets the request class. Defaults to Catalyst::Request.
896
897   $app->request_class_traits
898       An arrayref of Moose::Roles which are applied to the request class.
899       You can name the full namespace of the role, or a namespace suffix,
900       which will then be tried against the following standard namespace
901       prefixes.
902
903           $MyApp::TraitFor::Request::$trait_suffix
904           Catalyst::TraitFor::Request::$trait_suffix
905
906       So for example if you set:
907
908           MyApp->request_class_traits(['Foo']);
909
910       We try each possible role in turn (and throw an error if none load)
911
912           Foo
913           MyApp::TraitFor::Request::Foo
914           Catalyst::TraitFor::Request::Foo
915
916       The namespace part 'TraitFor::Request' was chosen to assist in
917       backwards compatibility with CatalystX::RoleApplicator which previously
918       provided these features in a stand alone package.
919
920   $app->composed_request_class
921       This is the request class which has been composed with any
922       request_class_traits.
923
924   $c->response_class
925       Returns or sets the response class. Defaults to Catalyst::Response.
926
927   $app->response_class_traits
928       An arrayref of Moose::Roles which are applied to the response class.
929       You can name the full namespace of the role, or a namespace suffix,
930       which will then be tried against the following standard namespace
931       prefixes.
932
933           $MyApp::TraitFor::Response::$trait_suffix
934           Catalyst::TraitFor::Response::$trait_suffix
935
936       So for example if you set:
937
938           MyApp->response_class_traits(['Foo']);
939
940       We try each possible role in turn (and throw an error if none load)
941
942           Foo
943           MyApp::TraitFor::Response::Foo
944           Catalyst::TraitFor::Responset::Foo
945
946       The namespace part 'TraitFor::Response' was chosen to assist in
947       backwards compatibility with CatalystX::RoleApplicator which previously
948       provided these features in a stand alone package.
949
950   $app->composed_response_class
951       This is the request class which has been composed with any
952       response_class_traits.
953
954   $c->read( [$maxlength] )
955       Reads a chunk of data from the request body. This method is designed to
956       be used in a while loop, reading $maxlength bytes on every call.
957       $maxlength defaults to the size of the request if not specified.
958
959       You have to set "MyApp->config(parse_on_demand => 1)" to use this
960       directly.
961
962       Warning: If you use read(), Catalyst will not process the body, so you
963       will not be able to access POST parameters or file uploads via
964       $c->request.  You must handle all body parsing yourself.
965
966   $c->run
967       Starts the engine.
968
969   $c->set_action( $action, $code, $namespace, $attrs )
970       Sets an action in a given namespace.
971
972   $c->setup_actions($component)
973       Sets up actions for a component.
974
975   $c->setup_components
976       This method is called internally to set up the application's
977       components.
978
979       It finds modules by calling the locate_components method, expands them
980       to package names with the expand_component_module method, and then
981       installs each component into the application.
982
983       The "setup_components" config option is passed to both of the above
984       methods.
985
986       Installation of each component is performed by the setup_component
987       method, below.
988
989   $app->setup_injected_components
990       Called by setup_compoents to setup components that are injected.
991
992   $app->setup_injected_component( $injected_component_name, $config )
993       Setup a given injected component.
994
995   $app->inject_component($MyApp_Component_name => \%args);
996       Add a component that is injected at setup:
997
998           MyApp->inject_component( 'Model::Foo' => { from_component => 'Common::Foo' } );
999
1000       Must be called before ->setup.  Expects a component name for your
1001       current application and \%args where
1002
1003       from_component
1004           The target component being injected into your application
1005
1006       roles
1007           An arrayref of Moose::Roles that are applied to your component.
1008
1009       Example
1010
1011           MyApp->inject_component(
1012             'Model::Foo' => {
1013               from_component => 'Common::Model::Foo',
1014               roles => ['Role1', 'Role2'],
1015             });
1016
1017   $app->inject_components
1018       Inject a list of components:
1019
1020           MyApp->inject_components(
1021             'Model::FooOne' => {
1022               from_component => 'Common::Model::Foo',
1023               roles => ['Role1', 'Role2'],
1024             },
1025             'Model::FooTwo' => {
1026               from_component => 'Common::Model::Foo',
1027               roles => ['Role1', 'Role2'],
1028             });
1029
1030   $c->locate_components( $setup_component_config )
1031       This method is meant to provide a list of component modules that should
1032       be setup for the application.  By default, it will use
1033       Module::Pluggable.
1034
1035       Specify a "setup_components" config option to pass additional options
1036       directly to Module::Pluggable. To add additional search paths, specify
1037       a key named "search_extra" as an array reference. Items in the array
1038       beginning with "::" will have the application class name prepended to
1039       them.
1040
1041   $c->expand_component_module( $component, $setup_component_config )
1042       Components found by "locate_components" will be passed to this method,
1043       which is expected to return a list of component (package) names to be
1044       set up.
1045
1046   $app->delayed_setup_component
1047       Returns a coderef that points to a setup_component instance.  Used
1048       internally for when you want to delay setup until the first time the
1049       component is called.
1050
1051   $c->setup_component
1052   $app->config_for( $component_name )
1053       Return the application level configuration (which is not yet merged
1054       with any local component configuration, via $component_class->config)
1055       for the named component or component object. Example:
1056
1057           MyApp->config(
1058             'Model::Foo' => { a => 1, b => 2},
1059           );
1060
1061           my $config = MyApp->config_for('MyApp::Model::Foo');
1062
1063       In this case $config is the hashref "{a=>1, b=>2}".
1064
1065       This is also handy for looking up configuration for a plugin, to make
1066       sure you follow existing Catalyst standards for where a plugin should
1067       put its configuration.
1068
1069   $c->setup_dispatcher
1070       Sets up dispatcher.
1071
1072   $c->setup_engine
1073       Sets up engine.
1074
1075   $c->apply_default_middlewares
1076       Adds the following Plack middlewares to your application, since they
1077       are useful and commonly needed:
1078
1079       Plack::Middleware::LighttpdScriptNameFix (if you are using Lighttpd),
1080       Plack::Middleware::IIS6ScriptNameFix (always applied since this
1081       middleware is smart enough to conditionally apply itself).
1082
1083       We will also automatically add Plack::Middleware::ReverseProxy if we
1084       notice that your HTTP $env variable "REMOTE_ADDR" is '127.0.0.1'.  This
1085       is usually an indication that your server is running behind a proxy
1086       frontend.  However in 2014 this is often not the case.  We preserve
1087       this code for backwards compatibility however I highly recommend that
1088       if you are running the server behind a front end proxy that you clearly
1089       indicate so with the "using_frontend_proxy" configuration setting to
1090       true for your environment configurations that run behind a proxy.  This
1091       way if you change your front end proxy address someday your code would
1092       inexplicably stop working as expected.
1093
1094       Additionally if we detect we are using Nginx, we add a bit of custom
1095       middleware to solve some problems with the way that server handles
1096       $ENV{PATH_INFO} and $ENV{SCRIPT_NAME}.
1097
1098       Please NOTE that if you do use "using_frontend_proxy" the middleware is
1099       now adding via "registered_middleware" rather than this method.
1100
1101       If you are using Lighttpd or IIS6 you may wish to apply these
1102       middlewares.  In general this is no longer a common case but we have
1103       this here for backward compatibility.
1104
1105   App->psgi_app
1106   App->to_app
1107       Returns a PSGI application code reference for the catalyst application
1108       $c. This is the bare application created without the
1109       "apply_default_middlewares" method called.  We do however apply
1110       "registered_middleware" since those are integral to how Catalyst
1111       functions.  Also, unlike starting your application with a generated
1112       server script (via Catalyst::Devel and "catalyst.pl") we do not attempt
1113       to return a valid PSGI application using any existing "${myapp}.psgi"
1114       scripts in your $HOME directory.
1115
1116       NOTE "apply_default_middlewares" was originally created when the first
1117       PSGI port was done for v5.90000.  These are middlewares that are added
1118       to achieve backward compatibility with older applications.  If you
1119       start your application using one of the supplied server scripts
1120       (generated with Catalyst::Devel and the project skeleton script
1121       "catalyst.pl") we apply "apply_default_middlewares" automatically.
1122       This was done so that pre and post PSGI port applications would work
1123       the same way.
1124
1125       This is what you want to be using to retrieve the PSGI application code
1126       reference of your Catalyst application for use in a custom .psgi or in
1127       your own created server modules.
1128
1129   $c->setup_home
1130       Sets up the home directory.
1131
1132   $c->setup_encoding
1133       Sets up the input/output encoding. See ENCODING
1134
1135   handle_unicode_encoding_exception
1136       Hook to let you customize how encoding errors are handled. By default
1137       we just throw an exception and the default error page will pick it up.
1138       Receives a hashref of debug information. Example of call (from the
1139       Catalyst internals):
1140
1141         my $decoded_after_fail = $c->handle_unicode_encoding_exception({
1142               param_value => $value,
1143               error_msg => $_,
1144               encoding_step => 'params',
1145          });
1146
1147       The calling code expects to receive a decoded string or an exception.
1148
1149       You can override this for custom handling of unicode errors. By default
1150       we just die. If you want a custom response here, one approach is to
1151       throw an HTTP style exception, instead of returning a decoded string or
1152       throwing a generic exception.
1153
1154           sub handle_unicode_encoding_exception {
1155             my ($c, $params) = @_;
1156             HTTP::Exception::BAD_REQUEST->throw(status_message=>$params->{error_msg});
1157           }
1158
1159       Alternatively you can 'catch' the error, stash it and write handling
1160       code later in your application:
1161
1162           sub handle_unicode_encoding_exception {
1163             my ($c, $params) = @_;
1164             $c->stash(BAD_UNICODE_DATA=>$params);
1165             # return a dummy string.
1166             return 1;
1167           }
1168
1169       <B>NOTE:</b> Please keep in mind that once an error like this occurs,
1170       the request setup is still ongoing, which means the state of $c and
1171       related context parts like the request and response may not be setup up
1172       correctly (since we haven't finished the setup yet). If you throw an
1173       exception the setup is aborted.
1174
1175   $c->setup_log
1176       Sets up log by instantiating a Catalyst::Log object and passing it to
1177       "log()". Pass in a comma-delimited list of levels to set the log to.
1178
1179       This method also installs a "debug" method that returns a true value
1180       into the catalyst subclass if the "debug" level is passed in the comma-
1181       delimited list, or if the $CATALYST_DEBUG environment variable is set
1182       to a true value.
1183
1184       Note that if the log has already been setup, by either a previous call
1185       to "setup_log" or by a call such as "__PACKAGE__->log( MyLogger->new
1186       )", that this method won't actually set up the log object.
1187
1188   $c->setup_plugins
1189       Sets up plugins.
1190
1191   $c->setup_stats
1192       Sets up timing statistics class.
1193
1194   $c->registered_plugins
1195       Returns a sorted list of the plugins which have either been stated in
1196       the import list.
1197
1198       If passed a given plugin name, it will report a boolean value
1199       indicating whether or not that plugin is loaded.  A fully qualified
1200       name is required if the plugin name does not begin with
1201       "Catalyst::Plugin::".
1202
1203        if ($c->registered_plugins('Some::Plugin')) {
1204            ...
1205        }
1206
1207   default_middleware
1208       Returns a list of instantiated PSGI middleware objects which is the
1209       default middleware that is active for this application (taking any
1210       configuration options into account, excluding your custom added
1211       middleware via the "psgi_middleware" configuration option).  You can
1212       override this method if you wish to change the default middleware
1213       (although do so at risk since some middleware is vital to application
1214       function.)
1215
1216       The current default middleware list is:
1217
1218             Catalyst::Middleware::Stash
1219             Plack::Middleware::HTTPExceptions
1220             Plack::Middleware::RemoveRedundantBody
1221             Plack::Middleware::FixMissingBodyInRedirect
1222             Plack::Middleware::ContentLength
1223             Plack::Middleware::MethodOverride
1224             Plack::Middleware::Head
1225
1226       If the configuration setting "using_frontend_proxy" is true we add:
1227
1228             Plack::Middleware::ReverseProxy
1229
1230       If the configuration setting "using_frontend_proxy_path" is true we
1231       add:
1232
1233             Plack::Middleware::ReverseProxyPath
1234
1235       But NOTE that Plack::Middleware::ReverseProxyPath is not a dependency
1236       of the Catalyst distribution so if you want to use this option you
1237       should add it to your project distribution file.
1238
1239       These middlewares will be added at "setup_middleware" during the
1240       "setup" phase of application startup.
1241
1242   registered_middlewares
1243       Read only accessor that returns an array of all the middleware in the
1244       order that they were added (which is the REVERSE of the order they will
1245       be applied).
1246
1247       The values returned will be either instances of Plack::Middleware or of
1248       a compatible interface, or a coderef, which is assumed to be inlined
1249       middleware
1250
1251   setup_middleware (?@middleware)
1252       Read configuration information stored in configuration key
1253       "psgi_middleware" or from passed @args.
1254
1255       See under "CONFIGURATION" information regarding "psgi_middleware" and
1256       how to use it to enable Plack::Middleware
1257
1258       This method is automatically called during 'setup' of your application,
1259       so you really don't need to invoke it.  However you may do so if you
1260       find the idea of loading middleware via configuration weird :).  For
1261       example:
1262
1263           package MyApp;
1264
1265           use Catalyst;
1266
1267           __PACKAGE__->setup_middleware('Head');
1268           __PACKAGE__->setup;
1269
1270       When we read middleware definitions from configuration, we reverse the
1271       list which sounds odd but is likely how you expect it to work if you
1272       have prior experience with Plack::Builder or if you previously used the
1273       plugin Catalyst::Plugin::EnableMiddleware (which is now considered
1274       deprecated)
1275
1276       So basically your middleware handles an incoming request from the first
1277       registered middleware, down and handles the response from the last
1278       middleware up.
1279
1280   registered_data_handlers
1281       A read only copy of registered Data Handlers returned as a Hash, where
1282       each key is a content type and each value is a subref that attempts to
1283       decode that content type.
1284
1285   setup_data_handlers (?@data_handler)
1286       Read configuration information stored in configuration key
1287       "data_handlers" or from passed @args.
1288
1289       See under "CONFIGURATION" information regarding "data_handlers".
1290
1291       This method is automatically called during 'setup' of your application,
1292       so you really don't need to invoke it.
1293
1294   default_data_handlers
1295       Default Data Handlers that come bundled with Catalyst.  Currently there
1296       are only two default data handlers, for 'application/json' and an
1297       alternative to 'application/x-www-form-urlencoded' which supposed
1298       nested form parameters via CGI::Struct or via CGI::Struct::XS IF you've
1299       installed it.
1300
1301       The 'application/json' data handler is used to parse incoming JSON into
1302       a Perl data structure.  It uses JSON::MaybeXS.  This allows you to fail
1303       back to JSON::PP, which is a Pure Perl JSON decoder, and has the
1304       smallest dependency impact.
1305
1306       Because we don't wish to add more dependencies to Catalyst, if you wish
1307       to use this new feature we recommend installing Cpanel::JSON::XS in
1308       order to get the best performance.  You should add either to your
1309       dependency list (Makefile.PL, dist.ini, cpanfile, etc.)
1310
1311   $c->stack
1312       Returns an arrayref of the internal execution stack (actions that are
1313       currently executing).
1314
1315   $c->stats
1316       Returns the current timing statistics object. By default Catalyst uses
1317       Catalyst::Stats, but can be set otherwise with stats_class.
1318
1319       Even if -Stats is not enabled, the stats object is still available. By
1320       enabling it with "$c->stats->enabled(1)", it can be used to profile
1321       explicitly, although MyApp.pm still won't profile nor output anything
1322       by itself.
1323
1324   $c->stats_class
1325       Returns or sets the stats (timing statistics) class. Catalyst::Stats is
1326       used by default.
1327
1328   $app->stats_class_traits
1329       A arrayref of Moose::Roles that are applied to the stats_class before
1330       creating it.
1331
1332   $app->composed_stats_class
1333       this is the stats_class composed with any 'stats_class_traits'.  You
1334       can name the full namespace of the role, or a namespace suffix, which
1335       will then be tried against the following standard namespace prefixes.
1336
1337           $MyApp::TraitFor::Stats::$trait_suffix
1338           Catalyst::TraitFor::Stats::$trait_suffix
1339
1340       So for example if you set:
1341
1342           MyApp->stats_class_traits(['Foo']);
1343
1344       We try each possible role in turn (and throw an error if none load)
1345
1346           Foo
1347           MyApp::TraitFor::Stats::Foo
1348           Catalyst::TraitFor::Stats::Foo
1349
1350       The namespace part 'TraitFor::Stats' was chosen to assist in backwards
1351       compatibility with CatalystX::RoleApplicator which previously provided
1352       these features in a stand alone package.
1353
1354   $c->use_stats
1355       Returns 1 when stats collection is enabled.
1356
1357       Note that this is a static method, not an accessor and should be
1358       overridden by declaring "sub use_stats { 1 }" in your MyApp.pm, not by
1359       calling "$c->use_stats(1)".
1360
1361   $c->write( $data )
1362       Writes $data to the output stream. When using this method directly, you
1363       will need to manually set the "Content-Length" header to the length of
1364       your output data, if known.
1365
1366   version
1367       Returns the Catalyst version number. Mostly useful for "powered by"
1368       messages in template systems.
1369

CONFIGURATION

1371       There are a number of 'base' config variables which can be set:
1372
1373       •   "always_catch_http_exceptions" - As of version 5.90060 Catalyst
1374           rethrows errors conforming to the interface described by
1375           Plack::Middleware::HTTPExceptions and lets the middleware deal with
1376           it.  Set true to get the deprecated behaviour and have Catalyst
1377           catch HTTP exceptions.
1378
1379       •   "default_model" - The default model picked if you say "$c->model".
1380           See "$c->model($name)".
1381
1382       •   "default_view" - The default view to be rendered or returned when
1383           "$c->view" is called. See "$c->view($name)".
1384
1385       •   "disable_component_resolution_regex_fallback" - Turns off the
1386           deprecated component resolution functionality so that if any of the
1387           component methods (e.g. "$c->controller('Foo')") are called then
1388           regex search will not be attempted on string values and instead
1389           "undef" will be returned.
1390
1391       •   "home" - The application home directory. In an uninstalled
1392           application, this is the top level application directory. In an
1393           installed application, this will be the directory containing
1394           "MyApp.pm".
1395
1396       •   "ignore_frontend_proxy" - See "PROXY SUPPORT"
1397
1398       •   "name" - The name of the application in debug messages and the
1399           debug and welcome screens
1400
1401       •   "parse_on_demand" - The request body (for example file uploads)
1402           will not be parsed until it is accessed. This allows you to (for
1403           example) check authentication (and reject the upload) before
1404           actually receiving all the data. See "ON-DEMAND PARSER"
1405
1406       •   "root" - The root directory for templates. Usually this is just a
1407           subdirectory of the home directory, but you can set it to change
1408           the templates to a different directory.
1409
1410       •   "search_extra" - Array reference passed to Module::Pluggable to for
1411           additional namespaces from which components will be loaded (and
1412           constructed and stored in "$c->components").
1413
1414       •   "show_internal_actions" - If true, causes internal actions such as
1415           "_DISPATCH" to be shown in hit debug tables in the test server.
1416
1417       •   "use_request_uri_for_path" - Controls if the "REQUEST_URI" or
1418           "PATH_INFO" environment variable should be used for determining the
1419           request path.
1420
1421           Most web server environments pass the requested path to the
1422           application using environment variables, from which Catalyst has to
1423           reconstruct the request base (i.e. the top level path to / in the
1424           application, exposed as "$c->request->base") and the request path
1425           below that base.
1426
1427           There are two methods of doing this, both of which have advantages
1428           and disadvantages. Which method is used is determined by the
1429           "$c->config(use_request_uri_for_path)" setting (which can either be
1430           true or false).
1431
1432           use_request_uri_for_path => 0
1433               This is the default (and the) traditional method that Catalyst
1434               has used for determining the path information.  The path is
1435               generated from a combination of the "PATH_INFO" and
1436               "SCRIPT_NAME" environment variables.  The allows the
1437               application to behave correctly when "mod_rewrite" is being
1438               used to redirect requests into the application, as these
1439               variables are adjusted by mod_rewrite to take account for the
1440               redirect.
1441
1442               However this method has the major disadvantage that it is
1443               impossible to correctly decode some elements of the path, as
1444               RFC 3875 says: ""Unlike a URI path, the PATH_INFO is not
1445               URL-encoded, and cannot contain path-segment parameters."" This
1446               means PATH_INFO is always decoded, and therefore Catalyst can't
1447               distinguish / vs %2F in paths (in addition to other encoded
1448               values).
1449
1450           use_request_uri_for_path => 1
1451               This method uses the "REQUEST_URI" and "SCRIPT_NAME"
1452               environment variables. As "REQUEST_URI" is never decoded, this
1453               means that applications using this mode can correctly handle
1454               URIs including the %2F character (i.e. with
1455               "AllowEncodedSlashes" set to "On" in Apache).
1456
1457               Given that this method of path resolution is provably more
1458               correct, it is recommended that you use this unless you have a
1459               specific need to deploy your application in a non-standard
1460               environment, and you are aware of the implications of not being
1461               able to handle encoded URI paths correctly.
1462
1463               However it also means that in a number of cases when the app
1464               isn't installed directly at a path, but instead is having paths
1465               rewritten into it (e.g. as a .cgi/fcgi in a public_html
1466               directory, with mod_rewrite in a .htaccess file, or when SSI is
1467               used to rewrite pages into the app, or when sub-paths of the
1468               app are exposed at other URIs than that which the app is
1469               'normally' based at with "mod_rewrite"), the resolution of
1470               "$c->request->base" will be incorrect.
1471
1472       •   "using_frontend_proxy" - See "PROXY SUPPORT".
1473
1474       •   "using_frontend_proxy_path" - Enabled
1475           Plack::Middleware::ReverseProxyPath on your application (if
1476           installed, otherwise log an error).  This is useful if your
1477           application is not running on the 'root' (or /) of your host
1478           server.  NOTE if you use this feature you should add the required
1479           middleware to your project dependency list since its not
1480           automatically a dependency of Catalyst.  This has been done since
1481           not all people need this feature and we wish to restrict the growth
1482           of Catalyst dependencies.
1483
1484       •   "encoding" - See "ENCODING"
1485
1486           This now defaults to 'UTF-8'.  You my turn it off by setting this
1487           configuration value to undef.
1488
1489       •   "abort_chain_on_error_fix"
1490
1491           Defaults to true.
1492
1493           When there is an error in an action chain, the default behavior is
1494           to abort the processing of the remaining actions to avoid running
1495           them when the application is in an unexpected state.
1496
1497           Before version 5.90070, the default used to be false. To keep the
1498           old behaviour, you can explicitly set the value to false. E.g.
1499
1500               __PACKAGE__->config(abort_chain_on_error_fix => 0);
1501
1502           If this setting is set to false, then the remaining actions are
1503           performed and the error is caught at the end of the chain.
1504
1505       •   "use_hash_multivalue_in_request"
1506
1507           In Catalyst::Request the methods "query_parameters",
1508           "body_parametes" and "parameters" return a hashref where values
1509           might be scalar or an arrayref depending on the incoming data.  In
1510           many cases this can be undesirable as it leads one to writing
1511           defensive code like the following:
1512
1513               my ($val) = ref($c->req->parameters->{a}) ?
1514                 @{$c->req->parameters->{a}} :
1515                   $c->req->parameters->{a};
1516
1517           Setting this configuration item to true will make Catalyst populate
1518           the attributes underlying these methods with an instance of
1519           Hash::MultiValue which is used by Plack::Request and others to
1520           solve this very issue.  You may prefer this behavior to the
1521           default, if so enable this option (be warned if you enable it in a
1522           legacy application we are not sure if it is completely backwardly
1523           compatible).
1524
1525       •   "skip_complex_post_part_handling"
1526
1527           When creating body parameters from a POST, if we run into a
1528           multipart POST that does not contain uploads, but instead contains
1529           inlined complex data (very uncommon) we cannot reliably convert
1530           that into field => value pairs.  So instead we create an instance
1531           of Catalyst::Request::PartData.  If this causes issue for you, you
1532           can disable this by setting "skip_complex_post_part_handling" to
1533           true (default is false).
1534
1535       •   "skip_body_param_unicode_decoding"
1536
1537           Generally we decode incoming POST params based on your declared
1538           encoding (the default for this is to decode UTF-8).  If this is
1539           causing you trouble and you do not wish to turn all encoding
1540           support off (with the "encoding" configuration parameter) you may
1541           disable this step atomically by setting this configuration
1542           parameter to true.
1543
1544       •   "do_not_decode_query"
1545
1546           If true, then do not try to character decode any wide characters in
1547           your request URL query or keywords.  Most readings of the relevant
1548           specifications suggest these should be UTF-* encoded, which is the
1549           default that Catalyst will use, however if you are creating a lot
1550           of URLs manually or have external evil clients, this might cause
1551           you trouble.  If you find the changes introduced in Catalyst
1552           version 5.90080+ break some of your query code, you may disable the
1553           UTF-8 decoding globally using this configuration.
1554
1555           This setting takes precedence over "default_query_encoding"
1556
1557       •   "do_not_check_query_encoding"
1558
1559           Catalyst versions 5.90080 - 5.90106 would decode query parts of an
1560           incoming request but would not raise an exception when the decoding
1561           failed due to incorrect unicode.  It now does, but if this change
1562           is giving you trouble you may disable it by setting this
1563           configuration to true.
1564
1565       •   "default_query_encoding"
1566
1567           By default we decode query and keywords in your request URL using
1568           UTF-8, which is our reading of the relevant specifications.  This
1569           setting allows one to specify a fixed value for how to decode your
1570           query.  You might need this if you are doing a lot of custom
1571           encoding of your URLs and not using UTF-8.
1572
1573       •   "use_chained_args_0_special_case"
1574
1575           In older versions of Catalyst, when more than one action matched
1576           the same path AND all those matching actions declared Args(0), we'd
1577           break the tie by choosing the first action defined.  We now
1578           normalized how Args(0) works so that it follows the same rule as
1579           Args(N), which is to say when we need to break a tie we choose the
1580           LAST action defined.  If this breaks your code and you don't have
1581           time to update to follow the new normalized approach, you may set
1582           this value to true and it will globally revert to the original
1583           chaining behavior.
1584
1585       •   "psgi_middleware" - See "PSGI MIDDLEWARE".
1586
1587       •   "data_handlers" - See "DATA HANDLERS".
1588
1589       •   "stats_class_traits"
1590
1591           An arrayref of Moose::Roles that get composed into your stats
1592           class.
1593
1594       •   "request_class_traits"
1595
1596           An arrayref of Moose::Roles that get composed into your request
1597           class.
1598
1599       •   "response_class_traits"
1600
1601           An arrayref of Moose::Roles that get composed into your response
1602           class.
1603
1604       •   "inject_components"
1605
1606           A Hashref of Catalyst::Component subclasses that are 'injected'
1607           into configuration.  For example:
1608
1609               MyApp->config({
1610                 inject_components => {
1611                   'Controller::Err' => { from_component => 'Local::Controller::Errors' },
1612                   'Model::Zoo' => { from_component => 'Local::Model::Foo' },
1613                   'Model::Foo' => { from_component => 'Local::Model::Foo', roles => ['TestRole'] },
1614                 },
1615                 'Controller::Err' => { a => 100, b=>200, namespace=>'error' },
1616                 'Model::Zoo' => { a => 2 },
1617                 'Model::Foo' => { a => 100 },
1618               });
1619
1620           Generally Catalyst looks for components in your Model/View or
1621           Controller directories.  However for cases when you which to use an
1622           existing component and you don't need any customization (where for
1623           when you can apply a role to customize it) you may inject those
1624           components into your application.  Please note any configuration
1625           should be done 'in the normal way', with a key under configuration
1626           named after the component affix, as in the above example.
1627
1628           Using this type of injection allows you to construct significant
1629           amounts of your application with only configuration!.  This may or
1630           may not lead to increased code understanding.
1631
1632           Please not you may also call the ->inject_components application
1633           method as well, although you must do so BEFORE setup.
1634

EXCEPTIONS

1636       Generally when you throw an exception inside an Action (or somewhere in
1637       your stack, such as in a model that an Action is calling) that
1638       exception is caught by Catalyst and unless you either catch it yourself
1639       (via eval or something like Try::Tiny or by reviewing the "error"
1640       stack, it will eventually reach "finalize_errors" and return either the
1641       debugging error stack page, or the default error page.  However, if
1642       your exception can be caught by Plack::Middleware::HTTPExceptions,
1643       Catalyst will instead rethrow it so that it can be handled by that
1644       middleware (which is part of the default middleware).  For example this
1645       would allow
1646
1647           use HTTP::Throwable::Factory 'http_throw';
1648
1649           sub throws_exception :Local {
1650             my ($self, $c) = @_;
1651
1652             http_throw(SeeOther => { location =>
1653               $c->uri_for($self->action_for('redirect')) });
1654
1655           }
1656

INTERNAL ACTIONS

1658       Catalyst uses internal actions like "_DISPATCH", "_BEGIN", "_AUTO",
1659       "_ACTION", and "_END". These are by default not shown in the private
1660       action table, but you can make them visible with a config parameter.
1661
1662           MyApp->config(show_internal_actions => 1);
1663

ON-DEMAND PARSER

1665       The request body is usually parsed at the beginning of a request, but
1666       if you want to handle input yourself, you can enable on-demand parsing
1667       with a config parameter.
1668
1669           MyApp->config(parse_on_demand => 1);
1670

PROXY SUPPORT

1672       Many production servers operate using the common double-server
1673       approach, with a lightweight frontend web server passing requests to a
1674       larger backend server. An application running on the backend server
1675       must deal with two problems: the remote user always appears to be
1676       127.0.0.1 and the server's hostname will appear to be "localhost"
1677       regardless of the virtual host that the user connected through.
1678
1679       Catalyst will automatically detect this situation when you are running
1680       the frontend and backend servers on the same machine. The following
1681       changes are made to the request.
1682
1683           $c->req->address is set to the user's real IP address, as read from
1684           the HTTP X-Forwarded-For header.
1685
1686           The host value for $c->req->base and $c->req->uri is set to the real
1687           host, as read from the HTTP X-Forwarded-Host header.
1688
1689       Additionally, you may be running your backend application on an
1690       insecure connection (port 80) while your frontend proxy is running
1691       under SSL.  If there is a discrepancy in the ports, use the HTTP header
1692       "X-Forwarded-Port" to tell Catalyst what port the frontend listens on.
1693       This will allow all URIs to be created properly.
1694
1695       In the case of passing in:
1696
1697           X-Forwarded-Port: 443
1698
1699       All calls to "uri_for" will result in an https link, as is expected.
1700
1701       Obviously, your web server must support these headers for this to work.
1702
1703       In a more complex server farm environment where you may have your
1704       frontend proxy server(s) on different machines, you will need to set a
1705       configuration option to tell Catalyst to read the proxied data from the
1706       headers.
1707
1708           MyApp->config(using_frontend_proxy => 1);
1709
1710       If you do not wish to use the proxy support at all, you may set:
1711
1712           MyApp->config(ignore_frontend_proxy => 0);
1713
1714   Note about psgi files
1715       Note that if you supply your own .psgi file, calling
1716       "MyApp->psgi_app(@_);", then this will not happen automatically.
1717
1718       You either need to apply Plack::Middleware::ReverseProxy yourself in
1719       your psgi, for example:
1720
1721           builder {
1722               enable "Plack::Middleware::ReverseProxy";
1723               MyApp->psgi_app
1724           };
1725
1726       This will unconditionally add the ReverseProxy support, or you need to
1727       call "$app = MyApp->apply_default_middlewares($app)" (to conditionally
1728       apply the support depending upon your config).
1729
1730       See Catalyst::PSGI for more information.
1731

THREAD SAFETY

1733       Catalyst has been tested under Apache 2's threading "mpm_worker",
1734       "mpm_winnt", and the standalone forking HTTP server on Windows. We
1735       believe the Catalyst core to be thread-safe.
1736
1737       If you plan to operate in a threaded environment, remember that all
1738       other modules you are using must also be thread-safe. Some modules,
1739       most notably DBD::SQLite, are not thread-safe.
1740

DATA HANDLERS

1742       The Catalyst::Request object uses HTTP::Body to populate 'classic' HTML
1743       form parameters and URL search query fields.  However it has become
1744       common for various alternative content types to be PUT or POSTed to
1745       your controllers and actions.  People working on RESTful APIs, or using
1746       AJAX often use JSON, XML and other content types when communicating
1747       with an application server.  In order to better support this use case,
1748       Catalyst defines a global configuration option, "data_handlers", which
1749       lets you associate a content type with a coderef that parses that
1750       content type into something Perl can readily access.
1751
1752           package MyApp::Web;
1753
1754           use Catalyst;
1755           use JSON::MaybeXS;
1756
1757           __PACKAGE__->config(
1758             data_handlers => {
1759               'application/json' => sub { local $/; decode_json $_->getline },
1760             },
1761             ## Any other configuration.
1762           );
1763
1764           __PACKAGE__->setup;
1765
1766       By default Catalyst comes with a generic JSON data handler similar to
1767       the example given above, which uses JSON::MaybeXS to provide either
1768       JSON::PP (a pure Perl, dependency free JSON parser) or Cpanel::JSON::XS
1769       if you have it installed (if you want the faster XS parser, add it to
1770       you project Makefile.PL or dist.ini, cpanfile, etc.)
1771
1772       The "data_handlers" configuration is a hashref whose keys are HTTP
1773       Content-Types (matched against the incoming request type using a regexp
1774       such as to be case insensitive) and whose values are coderefs that
1775       receive a localized version of $_ which is a filehandle object pointing
1776       to received body.
1777
1778       This feature is considered an early access release and we reserve the
1779       right to alter the interface in order to provide a performant and
1780       secure solution to alternative request body content.  Your reports
1781       welcomed!
1782

PSGI MIDDLEWARE

1784       You can define middleware, defined as Plack::Middleware or a compatible
1785       interface in configuration.  Your middleware definitions are in the
1786       form of an arrayref under the configuration key "psgi_middleware".
1787       Here's an example with details to follow:
1788
1789           package MyApp::Web;
1790
1791           use Catalyst;
1792           use Plack::Middleware::StackTrace;
1793
1794           my $stacktrace_middleware = Plack::Middleware::StackTrace->new;
1795
1796           __PACKAGE__->config(
1797             'psgi_middleware', [
1798               'Debug',
1799               '+MyApp::Custom',
1800               $stacktrace_middleware,
1801               'Session' => {store => 'File'},
1802               sub {
1803                 my $app = shift;
1804                 return sub {
1805                   my $env = shift;
1806                   $env->{myapp.customkey} = 'helloworld';
1807                   $app->($env);
1808                 },
1809               },
1810             ],
1811           );
1812
1813           __PACKAGE__->setup;
1814
1815       So the general form is:
1816
1817           __PACKAGE__->config(psgi_middleware => \@middleware_definitions);
1818
1819       Where @middleware is one or more of the following, applied in the
1820       REVERSE of the order listed (to make it function similarly to
1821       Plack::Builder:
1822
1823       Alternatively, you may also define middleware by calling the
1824       "setup_middleware" package method:
1825
1826           package MyApp::Web;
1827
1828           use Catalyst;
1829
1830           __PACKAGE__->setup_middleware( \@middleware_definitions);
1831           __PACKAGE__->setup;
1832
1833       In the case where you do both (use 'setup_middleware' and
1834       configuration) the package call to setup_middleware will be applied
1835       earlier (in other words its middleware will wrap closer to the
1836       application).  Keep this in mind since in some cases the order of
1837       middleware is important.
1838
1839       The two approaches are not exclusive.
1840
1841       Middleware Object
1842           An already initialized object that conforms to the
1843           Plack::Middleware specification:
1844
1845               my $stacktrace_middleware = Plack::Middleware::StackTrace->new;
1846
1847               __PACKAGE__->config(
1848                 'psgi_middleware', [
1849                   $stacktrace_middleware,
1850                 ]);
1851
1852       coderef
1853           A coderef that is an inlined middleware:
1854
1855               __PACKAGE__->config(
1856                 'psgi_middleware', [
1857                   sub {
1858                     my $app = shift;
1859                     return sub {
1860                       my $env = shift;
1861                       if($env->{PATH_INFO} =~m/forced/) {
1862                         Plack::App::File
1863                           ->new(file=>TestApp->path_to(qw/share static forced.txt/))
1864                           ->call($env);
1865                       } else {
1866                         return $app->($env);
1867                       }
1868                    },
1869                 },
1870               ]);
1871
1872       a scalar
1873           We assume the scalar refers to a namespace after normalizing it
1874           using the following rules:
1875
1876           (1) If the scalar is prefixed with a "+" (as in "+MyApp::Foo") then
1877           the full string is assumed to be 'as is', and we just install and
1878           use the middleware.
1879
1880           (2) If the scalar begins with "Plack::Middleware" or your
1881           application namespace (the package name of your Catalyst
1882           application subclass), we also assume then that it is a full
1883           namespace, and use it.
1884
1885           (3) Lastly, we then assume that the scalar is a partial namespace,
1886           and attempt to resolve it first by looking for it under your
1887           application namespace (for example if you application is
1888           "MyApp::Web" and the scalar is "MyMiddleware", we'd look under
1889           "MyApp::Web::Middleware::MyMiddleware") and if we don't find it
1890           there, we will then look under the regular Plack::Middleware
1891           namespace (i.e. for the previous we'd try
1892           "Plack::Middleware::MyMiddleware").  We look under your application
1893           namespace first to let you 'override' common Plack::Middleware
1894           locally, should you find that a good idea.
1895
1896           Examples:
1897
1898               package MyApp::Web;
1899
1900               __PACKAGE__->config(
1901                 'psgi_middleware', [
1902                   'Debug',  ## MyAppWeb::Middleware::Debug->wrap or Plack::Middleware::Debug->wrap
1903                   'Plack::Middleware::Stacktrace', ## Plack::Middleware::Stacktrace->wrap
1904                   '+MyApp::Custom',  ## MyApp::Custom->wrap
1905                 ],
1906               );
1907
1908       a scalar followed by a hashref
1909           Just like the previous, except the following "HashRef" is used as
1910           arguments to initialize the middleware object.
1911
1912               __PACKAGE__->config(
1913                 'psgi_middleware', [
1914                    'Session' => {store => 'File'},
1915               ]);
1916
1917       Please see PSGI for more on middleware.
1918

ENCODING

1920       Starting in Catalyst version 5.90080 encoding is automatically enabled
1921       and set to encode all body responses to UTF8 when possible and
1922       applicable.  Following is documentation on this process.  If you are
1923       using an older version of Catalyst you should review documentation for
1924       that version since a lot has changed.
1925
1926       By default encoding is now 'UTF-8'.  You may turn it off by setting the
1927       encoding configuration to undef.
1928
1929           MyApp->config(encoding => undef);
1930
1931       This is recommended for temporary backwards compatibility only.
1932
1933       To turn it off for a single request use the clear_encoding method to
1934       turn off encoding for this request.  This can be useful when you are
1935       setting the body to be an arbitrary block of bytes, especially if that
1936       block happens to be a block of UTF8 text.
1937
1938       Encoding is automatically applied when the content-type is set to a
1939       type that can be encoded.  Currently we encode when the content type
1940       matches the following regular expression:
1941
1942           $content_type =~ /^text|xml$|javascript$/
1943
1944       Encoding is set on the application, but it is copied to the context
1945       object so that you can override it on a request basis.
1946
1947       Be default we don't automatically encode 'application/json' since the
1948       most common approaches to generating this type of response (Either via
1949       Catalyst::View::JSON or Catalyst::Action::REST) will do so already and
1950       we want to avoid double encoding issues.
1951
1952       If you are producing JSON response in an unconventional manner (such as
1953       via a template or manual strings) you should perform the UTF8 encoding
1954       manually as well such as to conform to the JSON specification.
1955
1956       NOTE: We also examine the value of $c->response->content_encoding.  If
1957       you set this (like for example 'gzip', and manually gzipping the body)
1958       we assume that you have done all the necessary encoding yourself, since
1959       we cannot encode the gzipped contents.  If you use a plugin like
1960       Catalyst::Plugin::Compress you need to update to a modern version in
1961       order to have this function correctly  with the new UTF8 encoding code,
1962       or you can use Plack::Middleware::Deflater or (probably best) do your
1963       compression on a front end proxy.
1964
1965   Methods
1966       encoding
1967           Returns an instance of an "Encode" encoding
1968
1969               print $c->encoding->name
1970
1971       handle_unicode_encoding_exception ($exception_context)
1972           Method called when decoding process for a request fails.
1973
1974           An $exception_context hashref is provided to allow you to override
1975           the behaviour of your application when given data with incorrect
1976           encodings.
1977
1978           The default method throws exceptions in the case of invalid request
1979           parameters (resulting in a 500 error), but ignores errors in upload
1980           filenames.
1981
1982           The keys passed in the $exception_context hash are:
1983
1984           param_value
1985               The value which was not able to be decoded.
1986
1987           error_msg
1988               The exception received from Encode.
1989
1990           encoding_step
1991               What type of data was being decoded. Valid values are
1992               (currently) "params" - for request parameters / arguments /
1993               captures and "uploads" - for request upload filenames.
1994

SUPPORT

1996       IRC:
1997
1998           Join #catalyst on irc.perl.org.
1999
2000       Mailing Lists:
2001
2002           http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
2003           http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
2004
2005       Web:
2006
2007           http://catalyst.perl.org
2008
2009       Wiki:
2010
2011           http://dev.catalyst.perl.org
2012

SEE ALSO

2014   Task::Catalyst - All you need to start with Catalyst
2015   Catalyst::Manual - The Catalyst Manual
2016   Catalyst::Component, Catalyst::Controller - Base classes for components
2017   Catalyst::Engine - Core engine
2018   Catalyst::Log - Log class.
2019   Catalyst::Request - Request object
2020   Catalyst::Response - Response object
2021   Catalyst::Test - The test suite.

PROJECT FOUNDER

2023       sri: Sebastian Riedel <sri@cpan.org>
2024

CONTRIBUTORS

2026       abw: Andy Wardley
2027
2028       acme: Leon Brocard <leon@astray.com>
2029
2030       abraxxa: Alexander Hartmaier <abraxxa@cpan.org>
2031
2032       andrewalker: André Walker <andre@cpan.org>
2033
2034       Andrew Bramble
2035
2036       Andrew Ford <A.Ford@ford-mason.co.uk>
2037
2038       Andrew Ruthven
2039
2040       andyg: Andy Grundman <andy@hybridized.org>
2041
2042       audreyt: Audrey Tang
2043
2044       bricas: Brian Cassidy <bricas@cpan.org>
2045
2046       Caelum: Rafael Kitover <rkitover@io.com>
2047
2048       chansen: Christian Hansen
2049
2050       Chase Venters <chase.venters@gmail.com>
2051
2052       chicks: Christopher Hicks
2053
2054       Chisel Wright <pause@herlpacker.co.uk>
2055
2056       Danijel Milicevic <me@danijel.de>
2057
2058       davewood: David Schmidt <davewood@cpan.org>
2059
2060       David Kamholz <dkamholz@cpan.org>
2061
2062       David Naughton <naughton@umn.edu>
2063
2064       David E. Wheeler
2065
2066       dhoss: Devin Austin <dhoss@cpan.org>
2067
2068       dkubb: Dan Kubb <dan.kubb-cpan@onautopilot.com>
2069
2070       Drew Taylor
2071
2072       dwc: Daniel Westermann-Clark <danieltwc@cpan.org>
2073
2074       esskar: Sascha Kiefer
2075
2076       fireartist: Carl Franks <cfranks@cpan.org>
2077
2078       frew: Arthur Axel "fREW" Schmidt <frioux@gmail.com>
2079
2080       gabb: Danijel Milicevic
2081
2082       Gary Ashton Jones
2083
2084       Gavin Henry <ghenry@perl.me.uk>
2085
2086       Geoff Richards
2087
2088       groditi: Guillermo Roditi <groditi@gmail.com>
2089
2090       hobbs: Andrew Rodland <andrew@cleverdomain.org>
2091
2092       ilmari: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
2093
2094       jcamacho: Juan Camacho
2095
2096       jester: Jesse Sheidlower <jester@panix.com>
2097
2098       jhannah: Jay Hannah <jay@jays.net>
2099
2100       Jody Belka
2101
2102       Johan Lindstrom
2103
2104       jon: Jon Schutz <jjschutz@cpan.org>
2105
2106       Jonathan Rockway <jrockway@cpan.org>
2107
2108       Kieren Diment <kd@totaldatasolution.com>
2109
2110       konobi: Scott McWhirter <konobi@cpan.org>
2111
2112       marcus: Marcus Ramberg <mramberg@cpan.org>
2113
2114       miyagawa: Tatsuhiko Miyagawa <miyagawa@bulknews.net>
2115
2116       mgrimes: Mark Grimes <mgrimes@cpan.org>
2117
2118       mst: Matt S. Trout <mst@shadowcatsystems.co.uk>
2119
2120       mugwump: Sam Vilain
2121
2122       naughton: David Naughton
2123
2124       ningu: David Kamholz <dkamholz@cpan.org>
2125
2126       nothingmuch: Yuval Kogman <nothingmuch@woobling.org>
2127
2128       numa: Dan Sully <daniel@cpan.org>
2129
2130       obra: Jesse Vincent
2131
2132       Octavian Rasnita
2133
2134       omega: Andreas Marienborg
2135
2136       Oleg Kostyuk <cub.uanic@gmail.com>
2137
2138       phaylon: Robert Sedlacek <phaylon@dunkelheit.at>
2139
2140       rafl: Florian Ragwitz <rafl@debian.org>
2141
2142       random: Roland Lammel <lammel@cpan.org>
2143
2144       revmischa: Mischa Spiegelmock <revmischa@cpan.org>
2145
2146       Robert Sedlacek <rs@474.at>
2147
2148       rrwo: Robert Rothenberg <rrwo@cpan.org>
2149
2150       SpiceMan: Marcel Montes
2151
2152       sky: Arthur Bergman
2153
2154       szbalint: Balint Szilakszi <szbalint@cpan.org>
2155
2156       t0m: Tomas Doran <bobtfish@bobtfish.net>
2157
2158       Ulf Edvinsson
2159
2160       vanstyn: Henry Van Styn <vanstyn@cpan.org>
2161
2162       Viljo Marrandi <vilts@yahoo.com>
2163
2164       Will Hawes <info@whawes.co.uk>
2165
2166       willert: Sebastian Willert <willert@cpan.org>
2167
2168       wreis: Wallace Reis <wreis@cpan.org>
2169
2170       Yuval Kogman <nothingmuch@woobling.org>
2171
2172       rainboxx: Matthias Dietrich <perl@rainboxx.de>
2173
2174       dd070: Dhaval Dhanani <dhaval070@gmail.com>
2175
2176       Upasana <me@upasana.me>
2177
2178       John Napiorkowski (jnap) <jjnapiork@cpan.org>
2179
2181       Copyright (c) 2005-2015, the above named PROJECT FOUNDER and
2182       CONTRIBUTORS.
2183

LICENSE

2185       This library is free software. You can redistribute it and/or modify it
2186       under the same terms as Perl itself.
2187
2188
2189
2190perl v5.34.0                      2021-07-22                       Catalyst(3)
Impressum