THen in your layout, modify your css inclusion as follows:

<link rel="stylesheet" href="<% uri_base %>/css/style.css" /> 

From now on, you can mount your application wherever you want, without any further modification of the css inclusion

template and unicode------->模板和unicode

If you use Plack and have some unicode problem with your Dancer application, don't forget to check if you have set your template engine to use unicode, and set the default charset to UTF-8. So, if you are using template toolkit, your config.yml will look like this:

charset: UTF-8

engines:  

template_toolkit:

ENCODING: utf8 

TT's WRAPPER directive in Dancer (META variables, SETs)-------->TT'S包装指令

Dancer already provides a WRAPPER-like ability, which we call a "layout". The reason we do not use TT's WRAPPER (which also makes it incompatible with it) is because not all template systems support it. Actually, most don't.

一般不用TT's指令因为很多模板系统不支持，不兼容值，dancer提供了一个类包装的工具叫"layout"。

但是有时你还是会使用TT's包装指令比如：

定义META变量和常用的Template::Toolkit变量

However, you might want to use it, and be able to define META variables and regular Template::Toolkit variables.

These few steps will get you there:

取消layout

•Disable the layout in Dancer

You can do this by simply commenting (or removing) the layout configuration in the config.yml file.

使用Template Toolkit template engine

•Use Template Toolkit template engine

Change the configuration of the template to Template Toolkit:

# in config.ymltemplate: "template_toolkit" 

•Tell the Template Toolkit engine who's your wrapper

# in config.yml

# ...engines:

    template_toolkit: 

WRAPPER: layouts/main.tt 

Done! Everything will work fine out of the box, including variables and META variables.

SETTING THE STAGE: CONFIGURATION AND LOGGING

Configuration and environments

Configuring a Dancer application can be done in many ways. The easiest one (and maybe the the dirtiest) is to put all your settings statements at the top of your script, before calling the dance() method.

Other ways are possible, you can define all your settings in the file `appdir/config.yml'. For this, you must have installed the YAML module, and of course, write the config file in YAML.

That's better than the first option, but it's still not perfect as you can't switch easily from an environment to another without rewriting the config.yml file.

The better way is to have one config.yml file with default global settings, like the following:

# appdir/config.yml

logger: 'file'

layout: 'main' 

And then write as many environment files as you like in appdir/environments. That way, the appropriate environment config file will be loaded according to the running environment (if none is specified, it will be 'development').

Note that you can change the running environment using the --environment commandline switch.

Typically, you'll want to set the following values in a development config file:

# appdir/environments/development.yml

log: 'debug'

startup_info: 1

show_errors:  1 

And in a production one:

# appdir/environments/production.yml

log: 'warning'

startup_info: 0

show_errors:  0 

Accessing configuration information from your app

A Dancer application can use the 'config' keyword to easily access the settings within its config file, for instance:

下面的代码让我晕了好一阵子，首先，我以为要以真实的appname来代码字符串"appname"，其实不然，直接使用该代码即可，然后该代码只能返回appname的具体值，也就是说只能返回你的应用名称。要想返回其他内容还得需要下面的介绍。慢慢来!步子迈大了，扯着蛋疼，搞技术一定要慢慢来，别急，急不出真理。

get '/appname' => sub {

    return "This is " . config->{appname};

}; 

This makes keeping your application's settings all in one place simple and easy - you shouldn't need to worry about implementing all that yourself :)

Accessing configuration information from a separate script

You may well want to access your webapp's configuration from outside your webapp. You could, of course, use the YAML module of your choice and load your webapps's config.yml, but chances are that this is not convenient.

Use Dancer instead. Without any ado, magic or too big jumps, you can use the values from config.yml and some additional default values:

# bin/script1.pl

use Dancer ':script';

print "template:".config->{template}."\n"; #simple

print "log:".config->{log}."\n"; #undef 

Note that config->{log} should result undef error on a default scaffold since you did not load the environment and in the default scaffold log is defined in the environment and not in config.yml. Hence undef.

If you want to load an environment you need to tell Dancer where to look for it. One way to do so, is to tell Dancer where the webapp lives. From there Dancer deducts where the config.yml file is (typically $webapp/config.yml).

# bin/script2.pl

use FindBin;

use Cwd qw/realpath/;

use Dancer ':script'; 

#tell the Dancer where the app lives

my $appdir=realpath( "$FindBin::Bin/.."); 

Dancer::Config::setting('appdir',$appdir);

Dancer::Config::load(); 

#getter

print "environment:".config->{environment}."\n"; #development

print "log:".config->{log}."\n"; #value from development environment 

By default Dancer loads development environment (typically $webapp/environment/development.yml). In contrast to the example before, you do have a value from the development environment (environment/development.yml) now. Also note that in the above example Cwd and FindBin are used. They are likely to be already loaded by Dancer anyways, so it's not a big overhead. You could just as well hand over a simple path for the app if you like that better, e.g.:

Dancer::Config::setting('appdir','/path/to/app/dir'); 

If you want to load an environment other than the default, try this:

# bin/script2.pl

use Dancer ':script'; 

#tell the Dancer where the app lives

Dancer::Config::setting('appdir','/path/to/app/dir'); 

#which environment to load

config->{environment}='production'; 

Dancer::Config::load(); 

#getter

print "log:".config->{log}."\n"; #has value from production environment 

By the way, you not only get values, you can also set values straightforward like we do above with