.\" Automatically generated by Pod::Man 4.14 (Pod::Simple 3.43) .\" .\" Standard preamble: .\" ======================================================================== .de Sp \" Vertical space (when we can't use .PP) .if t .sp .5v .if n .sp .. .de Vb \" Begin verbatim text .ft CW .nf .ne \\$1 .. .de Ve \" End verbatim text .ft R .fi .. .\" Set up some character translations and predefined strings. \*(-- will .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left .\" double quote, and \*(R" will give a right double quote. \*(C+ will .\" give a nicer C++. Capital omega is used to do unbreakable dashes and .\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff, .\" nothing in troff, for use with C<>. .tr \(*W- .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' .ie n \{\ . ds -- \(*W- . ds PI pi . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch . ds L" "" . ds R" "" . ds C` "" . ds C' "" 'br\} .el\{\ . ds -- \|\(em\| . ds PI \(*p . ds L" `` . ds R" '' . ds C` . ds C' 'br\} .\" .\" Escape single quotes in literal strings from groff's Unicode transform. .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" .\" If the F register is >0, we'll generate index entries on stderr for .\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index .\" entries marked with X<> in POD. Of course, you'll have to process the .\" output yourself in some meaningful fashion. .\" .\" Avoid warning from groff about undefined register 'F'. .de IX .. .nr rF 0 .if \n(.g .if rF .nr rF 1 .if (\n(rF:(\n(.g==0)) \{\ . if \nF \{\ . de IX . tm Index:\\$1\t\\n%\t"\\$2" .. . if !\nF==2 \{\ . nr % 0 . nr F 2 . \} . \} .\} .rr rF .\" ======================================================================== .\" .IX Title "Catalyst::RouteMatching 3pm" .TH Catalyst::RouteMatching 3pm "2023-09-28" "perl v5.36.0" "User Contributed Perl Documentation" .\" For nroff, turn off justification. Always turn off hyphenation; it makes .\" way too many mistakes in technical documents. .if n .ad l .nh .SH "Name" .IX Header "Name" Catalyst::RouteMatching \- How Catalyst maps an incoming \s-1URL\s0 to actions in controllers. .SH "Description" .IX Header "Description" This is a \s-1WIP\s0 document intended to help people understand the logic that Catalyst uses to determine how to match in incoming request to an action (or action chain) in a controller. .SS "Request to Controller/Action Matching" .IX Subsection "Request to Controller/Action Matching" Catalyst maps requests to action using a 'longest path wins' approach. That means that if the request is '/foo/bar/baz' That means the action 'baz' matches: .PP .Vb 1 \& package MyApp::Controller::Foo; \& \& use Moose; \& use MooseX::MethodAttributes \& \& extends \*(AqCatalyst::Controller\*(Aq; \& \& sub bar :Path(\*(Aqbar\*(Aq) Args(1) { ...} \& sub baz :Path(\*(Aqbar/baz\*(Aq) Args(0) { ... } .Ve .PP Path length matches take precedence over all other types of matches (included \s-1HTTP\s0 Method, Scheme, etc.). The same holds true for Chained actions. Generally the chain that matches the most PathParts wins. .SS "Args(N) versus Args" .IX Subsection "Args(N) versus Args" \&'Args' matches any number of args. Because this functions as a sort of catchall, we treat 'Args' as the lowest precedence of any Args(N) when N is 0 to infinity. An action with 'Args' always get the last chance to match. .SS "When two or more actions match a given Path" .IX Subsection "When two or more actions match a given Path" Sometimes two or more actions match the same path and all have the same PathPart length. For example: .PP .Vb 1 \& package MyApp::Controller::Root; \& \& use Moose; \& use MooseX::MethodAttributes \& \& extends \*(AqCatalyst::Controller\*(Aq; \& \& sub root :Chained(/) CaptureArgs(0) { } \& \& sub one :Chained(root) PathPart(\*(Aq\*(Aq) Args(0) { } \& sub two :Chained(root) PathPart(\*(Aq\*(Aq) Args(0) { } \& sub three :Chained(root) PathPart(\*(Aq\*(Aq) Args(0) { } \& \& _\|_PACKAGE_\|_\->meta\->make_immutable; .Ve .PP In this case the last defined action wins (for the example that is action 'three'). .PP This is most common to happen when you are using action matching beyond paths, such as when using method matching: .PP .Vb 1 \& package MyApp::Controller::Root; \& \& use Moose; \& use MooseX::MethodAttributes \& \& extends \*(AqCatalyst::Controller\*(Aq; \& \& sub root :Chained(/) CaptureArgs(0) { } \& \& sub any :Chained(root) PathPart(\*(Aq\*(Aq) Args(0) { } \& sub get :GET Chained(root) PathPart(\*(Aq\*(Aq) Args(0) { } \& \& _\|_PACKAGE_\|_\->meta\->make_immutable; .Ve .PP In the above example \s-1GET\s0 /root could match both actions. In this case you should define your 'catchall' actions higher in the controller. .SS "Type Constraints in Args and Capture Args" .IX Subsection "Type Constraints in Args and Capture Args" Beginning in Version 5.90090+ you may use Moose, MooseX::Types or Type::Tiny type constraints to further declare allowed matching for Args or CaptureArgs. Here is a simple example: .PP .Vb 1 \& package MyApp::Controller::User; \& \& use Moose; \& use MooseX::MethodAttributes; \& use MooseX::Types::Moose qw(Int); \& \& extends \*(AqCatalyst::Controller\*(Aq; \& \& sub find :Path(\*(Aq\*(Aq) Args(Int) { \& my ($self, $c, $int) = @_; \& } \& \& _\|_PACKAGE_\|_\->meta\->make_immutable; .Ve .PP In this case the incoming request \*(L"http://localhost:/user/100\*(R" would match the action \&\f(CW\*(C`find\*(C'\fR but \*(L"http://localhost:/user/not_a_number\*(R" would not. You may find declaring constraints in this manner aids with debugging, automatic generation of documentation and reducing the amount of manual checking you might need to do in your actions. For example if the argument in the given action was going to be used to lookup a row in a database, if the matching field expected an integer, a string might cause a database exception, prompting you to add additional checking of the argument prior to using it. In general it is hoped this feature can lead to reduced validation boilerplate and more easily understood and declarative actions. .PP More than one argument may be added by comma separating your type constraint names, for example: .PP .Vb 1 \& use Types::Standard qw/Int Str/; \& \& sub find :Path(\*(Aq\*(Aq) Args(Int,Int,Str) { \& my ($self, $c, $int1, $int2, $str) = @_; \& } .Ve .PP Would require three arguments, an integer, integer and a string. Note in this example we constrained the args using imported types via Types::Standard. Although you may use stringy Moose types, we recommend imported types since this is less ambiguous to your readers. If you want to use Moose stringy types. you must quote them (either \*(L"Int\*(R" or 'Int' is fine). .PP Conversely, you should not quote types that are imported! .PP \fIUsing type constraints in a controller\fR .IX Subsection "Using type constraints in a controller" .PP By default Catalyst allows all the standard, built-in, named type constraints that come bundled with Moose. However it is trivial to create your own Type constraint libraries and export them to a controller that wishes to use them. We recommend using Type::Tiny or MooseX::Types for this. Here is an example using some extended type constraints via the Types::Standard library that is packaged with Type::Tiny: .PP .Vb 1 \& package MyApp::Controller::User; \& \& use Moose; \& use MooseX::MethodAttributes; \& use Types::Standard qw/StrMatch Int/; \& \& extends \*(AqCatalyst::Controller\*(Aq; \& \& sub looks_like_a_date :Path(\*(Aq\*(Aq) Args(StrMatch[qr{\ed\ed\-\ed\ed\-\ed\ed}]) { \& my ($self, $c, $int) = @_; \& } \& \& _\|_PACKAGE_\|_\->meta\->make_immutable; .Ve .PP This would match URLs like \*(L"http://localhost/user/11\-11\-2015\*(R" for example. If you've been missing the old RegExp matching, this can emulate a good chunk of that ability, and more. .PP A tutorial on how to make custom type libraries is outside the scope of this document. I'd recommend looking at the copious documentation in Type::Tiny or in MooseX::Types if you prefer that system. The author recommends Type::Tiny if you are unsure which to use. .PP \fIType constraint namespace.\fR .IX Subsection "Type constraint namespace." .PP By default we assume the namespace which defines the type constraint is in the package which contains the action declaring the arg or capture arg. However if you do not wish to import type constraints into you package, you may use a fully qualified namespace for your type constraint. If you do this you must install Type::Tiny which defines the code used to lookup and normalize the various types of Type constraint libraries. .PP Example: .PP .Vb 1 \& package MyApp::Example; \& \& use Moose; \& use MooseX::MethodAttributes; \& \& extends \*(AqCatalyst::Controller\*(Aq; \& \& sub an_int_ns :Local Args(MyApp::Types::Int) { \& my ($self, $c, $int) = @_; \& $c\->res\->body(\*(Aqan_int (withrole)\*(Aq); \& } .Ve .PP Would basically work the same as: .PP .Vb 1 \& package MyApp::Example; \& \& use Moose; \& use MooseX::MethodAttributes; \& use MyApp::Types \*(AqInt\*(Aq; \& \& extends \*(AqCatalyst::Controller\*(Aq; \& \& sub an_int_ns :Local Args(Int) { \& my ($self, $c, $int) = @_; \& $c\->res\->body(\*(Aqan_int (withrole)\*(Aq); \& } .Ve .PP \fInamespace::autoclean\fR .IX Subsection "namespace::autoclean" .PP If you want to use namespace::autoclean in your controllers you must 'except' imported type constraints since the code that resolves type constraints in args / capture args run after the cleaning. For example: .PP .Vb 1 \& package MyApp::Controller::Autoclean; \& \& use Moose; \& use MooseX::MethodAttributes; \& use namespace::autoclean \-except => \*(AqInt\*(Aq; \& use MyApp::Types qw/Int/; \& \& extends \*(AqCatalyst::Controller\*(Aq; \& \& sub an_int :Local Args(Int) { \& my ($self, $c, $int) = @_; \& $c\->res\->body(\*(Aqan_int (autoclean)\*(Aq); \& } .Ve .PP \fIUsing roles and base controller with type constraints\fR .IX Subsection "Using roles and base controller with type constraints" .PP If your controller is using a base class or a role that has an action with a type constraint you should declare your use of the type constraint in that role or base controller in the same way as you do in main controllers. Catalyst will try to find the package with declares the type constraint first by looking in any roles and then in superclasses. It will use the first package that defines the type constraint. For example: .PP .Vb 1 \& package MyApp::Role; \& \& use Moose::Role; \& use MooseX::MethodAttributes::Role; \& use MyApp::Types qw/Int/; \& \& sub an_int :Local Args(Int) { \& my ($self, $c, $int) = @_; \& $c\->res\->body(\*(Aqan_int (withrole)\*(Aq); \& } \& \& sub an_int_ns :Local Args(MyApp::Types::Int) { \& my ($self, $c, $int) = @_; \& $c\->res\->body(\*(Aqan_int (withrole)\*(Aq); \& } \& \& package MyApp::BaseController; \& \& use Moose; \& use MooseX::MethodAttributes; \& use MyApp::Types qw/Int/; \& \& extends \*(AqCatalyst::Controller\*(Aq; \& \& sub from_parent :Local Args(Int) { \& my ($self, $c, $id) = @_; \& $c\->res\->body(\*(Aqfrom_parent $id\*(Aq); \& } \& \& package MyApp::Controller::WithRole; \& \& use Moose; \& use MooseX::MethodAttributes; \& \& extends \*(AqMyApp::BaseController\*(Aq; \& \& with \*(AqMyApp::Role\*(Aq; .Ve .PP If you have complex controller hierarchy, we do not at this time attempt to look for all packages with a match type constraint, but instead take the first one found. In the future we may add code that attempts to insure a sane use of subclasses with type constraints but right now there are no clear use cases so report issues and interests. .PP \fIMatch order when more than one Action matches a path.\fR .IX Subsection "Match order when more than one Action matches a path." .PP As previously described, Catalyst will match 'the longest path', which generally means that named path / path_parts will take precedence over Args or CaptureArgs. However, what will happen if two actions match the same path with equal args? For example: .PP .Vb 2 \& sub an_int :Path(user) Args(Int) { \& } \& \& sub an_any :Path(user) Args(1) { \& } .Ve .PP In this case Catalyst will check actions starting from the \s-1LAST\s0 one defined. Generally this means you should put your most specific action rules \s-1LAST\s0 and your 'catch\-alls' first. In the above example, since \fBArgs\fR\|(1) will match any argument, you will find that that 'an_int' action \s-1NEVER\s0 gets hit. You would need to reverse the order: .PP .Vb 2 \& sub an_any :Path(user) Args(1) { \& } \& \& sub an_int :Path(user) Args(Int) { \& } .Ve .PP Now requests that match this path would first hit the 'an_int' action and will check to see if the argument is an integer. If it is, then the action will execute, otherwise it will pass and the dispatcher will check the next matching action (in this case we fall through to the 'an_any' action). .PP \fIType Constraints and Chained Actions\fR .IX Subsection "Type Constraints and Chained Actions" .PP Using type constraints in Chained actions works the same as it does for Path and Local or Global actions. The only difference is that you may declare type constraints on CaptureArgs as well as Args. For Example: .PP .Vb 1 \& use Types::Standard qw/Int Tuple/; \& \& sub chain_base :Chained(/) CaptureArgs(1) { } \& \& sub any_priority_chain :GET Chained(chain_base) PathPart(\*(Aq\*(Aq) Args(1) { } \& \& sub int_priority_chain :Chained(chain_base) PathPart(\*(Aq\*(Aq) Args(Int) { } \& \& sub link_any :Chained(chain_base) PathPart(\*(Aq\*(Aq) CaptureArgs(1) { } \& \& sub any_priority_link_any :Chained(link_any) PathPart(\*(Aq\*(Aq) Args(1) { } \& \& sub int_priority_link_any :Chained(link_any) PathPart(\*(Aq\*(Aq) Args(Int) { } \& \& sub link_int :Chained(chain_base) PathPart(\*(Aq\*(Aq) CaptureArgs(Int) { } \& \& sub any_priority_link :Chained(link_int) PathPart(\*(Aq\*(Aq) Args(1) { } \& \& sub int_priority_link :Chained(link_int) PathPart(\*(Aq\*(Aq) Args(Int) { } \& \& sub link_int_int :Chained(chain_base) PathPart(\*(Aq\*(Aq) CaptureArgs(Int,Int) { } \& \& sub any_priority_link2 :Chained(link_int_int) PathPart(\*(Aq\*(Aq) Args(1) { } \& \& sub int_priority_link2 :Chained(link_int_int) PathPart(\*(Aq\*(Aq) Args(Int) { } \& \& sub link_tuple :Chained(chain_base) PathPart(\*(Aq\*(Aq) CaptureArgs(Tuple[Int,Int,Int]) { } \& \& sub any_priority_link3 :Chained(link_tuple) PathPart(\*(Aq\*(Aq) Args(1) { } \& \& sub int_priority_link3 :Chained(link_tuple) PathPart(\*(Aq\*(Aq) Args(Int) { } .Ve .PP These chained actions might create match tables like the following: .PP .Vb 10 \& [debug] Loaded Chained actions: \& .\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-. \& | Path Spec | Private | \& +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ \& | /chain_base/*/* | /chain_base (1) | \& | | => GET /any_priority_chain (1) | \& | /chain_base/*/*/* | /chain_base (1) | \& | | \-> /link_int (Int) | \& | | => /any_priority_link (1) | \& | /chain_base/*/*/*/* | /chain_base (1) | \& | | \-> /link_int_int (Int,Int) | \& | | => /any_priority_link2 (1) | \& | /chain_base/*/*/*/*/* | /chain_base (1) | \& | | \-> /link_tuple (Tuple[Int,Int,Int]) | \& | | => /any_priority_link3 (1) | \& | /chain_base/*/*/* | /chain_base (1) | \& | | \-> /link_any (1) | \& | | => /any_priority_link_any (1) | \& | /chain_base/*/*/*/*/*/* | /chain_base (1) | \& | | \-> /link_tuple (Tuple[Int,Int,Int]) | \& | | \-> /link2_int (UserId) | \& | | => GET /finally (Int) | \& | /chain_base/*/*/*/*/*/... | /chain_base (1) | \& | | \-> /link_tuple (Tuple[Int,Int,Int]) | \& | | \-> /link2_int (UserId) | \& | | => GET /finally2 (...) | \& | /chain_base/*/* | /chain_base (1) | \& | | => /int_priority_chain (Int) | \& | /chain_base/*/*/* | /chain_base (1) | \& | | \-> /link_int (Int) | \& | | => /int_priority_link (Int) | \& | /chain_base/*/*/*/* | /chain_base (1) | \& | | \-> /link_int_int (Int,Int) | \& | | => /int_priority_link2 (Int) | \& | /chain_base/*/*/*/*/* | /chain_base (1) | \& | | \-> /link_tuple (Tuple[Int,Int,Int]) | \& | | => /int_priority_link3 (Int) | \& | /chain_base/*/*/* | /chain_base (1) | \& | | \-> /link_any (1) | \& | | => /int_priority_link_any (Int) | \& \*(Aq\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\*(Aq .Ve .PP As you can see the same general path could be matched by various action chains. In this case the rule described in the previous section should be followed, which is that Catalyst will start with the last defined action and work upward. For example the action \f(CW\*(C`int_priority_chain\*(C'\fR would be checked before \f(CW\*(C`any_priority_chain\*(C'\fR. The same applies for actions that are midway links in a longer chain. In this case \f(CW\*(C`link_int\*(C'\fR would be checked before \f(CW\*(C`link_any\*(C'\fR. So as always we recommend that you place you priority or most constrained actions last and you least or catch-all actions first. .PP Although this reverse order checking may seen counter intuitive it does have the added benefit that when inheriting controllers any new actions added would take check precedence over those in your parent controller or consumed role. .PP Please note that your declared type constraint names will now appear in the debug console. .SH "Author" .IX Header "Author" John Napiorkowski jjnapiork@cpan.org