|o||It sets the default charset of outgoing content. charset= item will be added to Content-Type response header.|
|o||It makes Unicode bodies in HTTP responses of text/* types to be encoded to this charset.|
|o||It also indicates to Dancer2 in which charset the static files and templates are encoded.|
|o||If youre using Dancer2::Plugin::Database, UTF-8 support will automatically be enabled for your database - see AUTOMATIC UTF-8 SUPPORT in Dancer2::Plugin::Database|
You can cancel any charset processing by specifying your own charset in Content-Type header or by ensuring that response body leaves your handler without Unicode flag set (by encoding it into some 8bit charset, for example).
Also, since automatically serialized JSON responses have application/json Content-Type, you should always encode them by hand.
Dancer2s Dancer2::Core::MIME module uses application/data as a default mime type. This setting lets the user change it. For example, if you have a lot of files being served in the <B>publicB> folder that do not have an extension, and are text files, set the default_mime_type to text/plain.
This is the name of the environment that should be used. Standard Dancer2 applications have a environments folder with specific configuration files for different environments (usually development and production environments). They specify different kind of error reporting, deployment details, etc. These files are read after the generic config.yml configuration file.
The running environment can be set with:
set environment => "production";
Note that this variable is also used as a default value if other values are not defined.
This is the path where your application will live. Its where Dancer2 will look by default for your config files, templates and static content.
It is typically set by use Dancer2 to use the same directory as your script.
This is the directory, where static files are stored. Any existing file in that directory will be served as a static file, before matching any route.
This is the directory where your templates and layouts live. Its the view part of MVC (model, view, controller).
Allows you to configure which template engine should be used. For instance, to use Template Toolkit, add the following to config.yml:
The name of the layout to use when rendering view. Dancer2 will look for a matching template in the directory $views/layouts.
Your can override the default layout using the third argument of the template keyword. Check Dancer2 manpage for details.
A relative path where the layouts reside inside the views directory.
strict_config (boolean, default: false)
If set to true, prints a banner at the server start with information such as versions and the environment (or dancefloor).
Conforms to the environment variable DANCER_STARTUP_INFO.
You can also use the environment variable DANCER_NO_SERVER_TOKENS.
Select which logger to use. For example, to write to log files with Dancer2::Logger::File:
Loggers are configured with a corresponding Logger engine section, as shown below.
This setting lets you enable a session engine for your web application. By default, sessions are disabled in Dancer2, you must choose a session engine to use them.
Sessions are configured with a corresponding Session engine section, as shown below.
If set to true, Dancer2 will render a detailed debug screen whenever an error is caught. If set to false, Dancer2 will render the default error page, using $public/$error_code.html if it exists, $views/$error_code.tt or the template specified by the error_template setting.
The error screen attempts to sanitise sensitive looking information (passwords / card numbers in the request, etc) but you still should not have show_errors enabled whilst in production, as there is still a risk of divulging details.
error_template (template path)
This setting lets you specify a template to be used in case of runtime error. At the present moment the template (as well as $views/$error_code.tt templates) can use four variables:
Keep in mind that content and exception can vary depending on the problem.
<B>titleB> The error title. <B>contentB> The error specific content (if any). <B>statusB> The HTTP status code throwing that error. <B>exceptionB> The stringified exception (e.g. $@) if any.
A 404 has an empty exception and content contains the URI that was not found. Unless you do the 404 yourself via send_error("You chose ... poorly!", 404);, then content is You chose ... poorly!.
A 500 because of, say, dividing 0 by 0 will have an empty content and exception like Illegal division by zero at ....
A 401 from send_error("You can not know the secret until you sign in grasshopper!", 401); will have an empty exception and content will contain You can not know the secret until you sign in grasshopper!.
The logger must be configured in a separate engines section, like so:
logger: Console engines: logger: Console: log_level: core
All loggers support the configuration options below. See documentation for a particular logger for other supported options.
During development, youll probably want to use debug to see your own debug messages, and core if you need to see what Dancer2 is doing. In production, youll likely want error or warning only, for less-chatty logs.
<B>coreB> : all messages are logged, including some from Dancer2 itself <B>debugB> : all messages are logged <B>infoB> : only info, warning and error messages are logged <B>warningB> : only warning and error messages are logged <B>errorB> : only error messages are logged
The session engine is configured in the engines section.
session: Simple engines: session: Simple: cookie_name: dance.set cookie_duration: 24 hours is_secure: 1 is_http_only: 1
See Dancer2::Core::Role::SessionFactory for more detailed documentation for these options, or the particular session engine for other supported options.
The name of the cookie to store the session ID in. Defaults to dancer.session. This can be overridden by certain session engines.
The domain of the cookie. By default there is no domain defined for the cookie.
The path of the cookie. By default there is no path defined for the cookie.
The session expiry time in seconds, or as e.g. 2 hours (see expires in Dancer2::Core::Cookie. By default, there is no specific expiry time.
The users session ID is stored in a cookie. If the is_secure setting is set to a true value, the cookie will be marked as secure, meaning it should only be sent over HTTPS connections.
For simple pages where youre not doing anything dynamic, but still want to use the template engine to provide headers etc, you can use the auto_page feature to avoid the need to create a route for each page.
Simply enable auto_page in your config:
Dancer2 will honor your before_template_render code, and all default variables. They will be accessible and interpolated on automatic served pages.
For complex applications that require extended DSL keywords or other functionality the DSL class used can be specified at import time or in the config settings.
This is the same as specifying
use Dancer2 dsl => My::DSL
Sets the configuration directory.
This correlates to the confdir config option.
Sets the environment directory.
This correlates to the envdir config option.
Sets the given environment. This can be overridden by DANCER_ENVIRONMENT.
Sets the given environment. This takes higher precedence over PLACK_ENV.
The DANCER_APPHANDLER configuration controls what the dance keyword does.
Otherwise (which is the default is - Standalone), it runs the Plack standalone server with the application.
Controls whether to display start up info.
Controls whether to display the server tokens.
Sets the public directory location.
Sets the tracing flag which sets Carps $Verbose flag.
Sets the views (templates) directory.
Sets the logger engine.
Sets the default charset.
Sets the default content type.
Dancer Core Developers
This software is copyright (c) 2015 by Alexis Sukrieh.
This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.
|perl v5.20.3||DANCER2::CONFIG (3)||2016-01-22|