Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

plack::app::urlmap(3pm) [debian man page]

Plack::App::URLMap(3pm) 				User Contributed Perl Documentation				   Plack::App::URLMap(3pm)

NAME
Plack::App::URLMap - Map multiple apps in different paths SYNOPSIS
use Plack::App::URLMap; my $app1 = sub { ... }; my $app2 = sub { ... }; my $app3 = sub { ... }; my $urlmap = Plack::App::URLMap->new; $urlmap->map("/" => $app1); $urlmap->map("/foo" => $app2); $urlmap->map("http://bar.example.com/" => $app3); my $app = $urlmap->to_app; DESCRIPTION
Plack::App::URLMap is a PSGI application that can dispatch multiple applications based on URL path and hostnames (a.k.a "virtual hosting") and takes care of rewriting "SCRIPT_NAME" and "PATH_INFO" (See "HOW THIS WORKS" for details). This module is inspired by Rack::URLMap. METHODS
map $urlmap->map("/foo" => $app); $urlmap->map("http://bar.example.com/" => $another_app); Maps URL path or an absolute URL to a PSGI application. The match order is sorted by host name length and then path length. URL paths need to match from the beginning and should match completely till the path separator (or the end of the path). For example, if you register the path "/foo", it will match with the request "/foo", "/foo/" or "/foo/bar" but it won't match with "/foox". Mapping URL with host names is also possible, and in that case the URL mapping works like a virtual host. Mappings will nest. If $app is already mapped to "/baz" it will match a request for "/foo/baz" but not "/foo". See "HOW THIS WORKS" for more details. mount Alias for "map". to_app my $handler = $urlmap->to_app; Returns the PSGI application code reference. Note that the Plack::App::URLMap object is callable (by overloading the code dereference), so returning the object itself as a PSGI application should also work. DEBUGGING
You can set the environment variable "PLACK_URLMAP_DEBUG" to see how this application matches with the incoming request host names and paths. HOW THIS WORKS
This application works by fixing "SCRIPT_NAME" and "PATH_INFO" before dispatching the incoming request to the relocated applications. Say you have a Wiki application that takes "/index" and "/page/*" and makes a PSGI application $wiki_app out of it, using one of supported web frameworks, you can put the whole application under "/wiki" by: # MyWikiApp looks at PATH_INFO and handles /index and /page/* my $wiki_app = sub { MyWikiApp->run(@_) }; use Plack::App::URLMap; my $app = Plack::App::URLMap->new; $app->mount("/wiki" => $wiki_app); When a request comes in with "PATH_INFO" set to "/wiki/page/foo", the URLMap application $app strips the "/wiki" part from "PATH_INFO" and appends that to "SCRIPT_NAME". That way, if the $app is mounted under the root (i.e. "SCRIPT_NAME" is "") with standalone web servers like Starman, "SCRIPT_NAME" is now locally set to "/wiki" and "PATH_INFO" is changed to "/page/foo" when $wiki_app gets called. AUTHOR
Tatsuhiko Miyagawa SEE ALSO
Plack::Builder perl v5.14.2 2011-06-22 Plack::App::URLMap(3pm)

Check Out this Related Man Page

Plack::Component(3pm)					User Contributed Perl Documentation				     Plack::Component(3pm)

NAME
Plack::Component - Base class for PSGI endpoints SYNOPSIS
package Plack::App::Foo; use parent qw( Plack::Component ); sub call { my($self, $env) = @_; # Do something with $env my $res = ...; # create a response ... # return the response return $res; } DESCRIPTION
Plack::Component is the base class shared between Plack::Middleware and Plack::App::* modules. If you are writing middleware, you should inherit from Plack::Middleware, but if you are writing a Plack::App::* you should inherit from this directly. REQUIRED METHOD
call ($env) You are expected to implement a "call" method in your component. This is where all the work gets done. It receives the PSGI $env hash- ref as an argument and is expected to return a proper PSGI response value. METHODS
new (%opts | \%opts) The constructor accepts either a hash or a hash-ref and uses that to create the instance with. It will call no other methods and simply return the instance that is created. prepare_app This method is called by "to_app" and is meant as a hook to be used to prepare your component before it is packaged as a PSGI $app. to_app This is the method used in several parts of the Plack infrastructure to convert your component into a PSGI $app. You should not ever need to override this method, it is recommended to use "prepare_app" and "call" instead. response_cb This is a wrapper for "response_cb" in Plack::Util. See "RESPONSE CALLBACK" in Plack::Middleware for details. OBJECT LIFECYCLE
Objects for the derived classes (Plack::App::* or Plack::Middleware::*) are created at the PSGI application compile phase using "new", "prepare_app" and "to_app", and the created object persists during the web server lifecycle, unless it is running on the non-persistent environment like CGI. "call" is invoked against the same object whenever a new request comes in. You can check if it is running in a persistent environment by checking "psgi.run_once" key in the $env being true (non-persistent) or false (persistent), but it is best for you to write your middleware safely for a persistent environment. To accomplish that, you should avoid saving per-request data like $env in your object. BACKWARDS COMPATIBILITY
The Plack::Middleware module used to inherit from Class::Accessor::Fast, which has been removed in favor of the Plack::Util::Accessor module. When developing new components it is recommended to use Plack::Util::Accessor like so: use Plack::Util::Accessor qw( foo bar baz ); However, in order to keep backwards compatibility this module provides a "mk_accessors" method similar to Class::Accessor::Fast. New code should not use this and use Plack::Util::Accessor instead. SEE ALSO
Plack Plack::Builder Plack::Middleware perl v5.14.2 2011-06-22 Plack::Component(3pm)
Man Page