Thanks for the information, I'm running into some problems, see below. On Fri, Feb 25, 2011 at 9:10 AM, Flavio Poletti <polettix@gmail.com> wrote:

0. You pay only for what you use:    perl -MDancer -e 'get "/" => sub {return "Hello, World!"}; dance' 1. There seems to be an undocumented configuration feature that lets you specify the base directory for templates:    perl -MDancer -e 'set views => "foo"; get "/" => sub {template "bar"}; dance' (this takes foo/bar.tt instead of views/bar.tt), I wonder if this can be made official and documented.

I can't seem to get this to work. When I use this "set views" as you suggested or views: in the config file, it sets the "views" config to that dir (say, "templates", and I verified this by Dumping the config hash), but I always get 404. This is problem #1, when I get a 404 I get no detailed information in the logs whatsoever. I get nothing in development.log actually. In this case, I know what the problem is (will say it in a second), but it would be really nice if Dancer would tell me somewhere what the problem is. 404 can mean route not found but apparently also view/template not found. There should be some way to disambiguate this fact. The problem is that it's looking in the wrong place for the "templates" directory. I don't know where it's looking, but it's not looking in appdir/templates. If I set views => '/full/path/to/templates' it works, but if I use what I intend to be a relative directory I just get 404 error messages. Setting to app_dir . templates works if I set it in the code, but I can't figure out how to use "appdir" in config.yml (I'd rather set it in config.yml than in code). This isn't really a big deal. My real problem is that we have a function called template which looks in the views directory. This terminology mismatch is disconcerting. Since most perl modules call everything templates and the function is named template it seems like the files should be in "templates." However, if we like the "views" terminology we should just name the function "view" instead. Or figure out what I'm doing wrong with the config :) I realize this is undocumented behavior and I can't expect it to work. I'm going to follow the convention and use "views" for now.

2. No restriction regarding the project directory name, just try it :-) The normal startup script is a standard Perl program: #!/usr/bin/env perl use Dancer; use WhateverName::YouLike::ForYour::DancerApplication; dance;

Cheers,     Flavio.

On Fri, Feb 25, 2011 at 5:03 PM, Brian E. Lozier <brian@massassi.com> wrote:

...

I'm going to do a test implementation of a dancer web app into an existing project.  I would like to know the minimum files I need to create in order to get it running.  My intention is not to use the scaffolding script to create files as 1) it creates a bunch of files I don't need [but I don't know which ones are strictly required], 2) it creates a directory structure designed to house all my code, but I already have a directory structure [that might not match Dancer's exactly], and 3) I find scaffolding scripts hide a bunch of information that it's really better for me to understand instead of gloss over.  I would essentially like to start from scratch.  If there is not already documentation on this and I get some feedback here, I'll be happy to write a document and submit it back to the list.

I have a couple other questions as well.

1. Is it possible for me to specify the "templates" directory as something other than "views" (we use "template" function in the code, it makes more sense to load it from a "templates" directory instead of a "views" directory)? 2. Is there an in-code restriction that requires me to have the directory name of my project (like "myproject") match the name of the dancer app module (myproject.pm)?  I ask because it's not perlish to have a lower-cased module (like myproject.pm) but I don't want to name my directory MyProject because it's annoying to type.  Generally lower case module names are reserved for pragmas (like warnings, strict, feature, etc.).

Thanks in advance for any help, Brian _______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users

_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users

Indeed your example works. I may have left out a crucial bit or two of information. First, I am using layouts and it's unclear whether the 404 was for the layout or the regular template so I added it to your example. I put my "eg.pl" in a dir called bin/, I was copying the layout of the scaffolded test project I had created earlier. So I have: /tmp /tmp/bin/eg.pl /tmp/tmpls/test.tt /tmp/tmpls/layouts/main.tt and /tmp/bin/eg.pl looks like this: use Dancer; set layout => 'main.tt'; set views => 'tmpls'; get '/' => sub { template 'test.tt'; }; dance; It works from /tmp/eg.pl but when put in /tmp/bin I get the 404 error. To clarify, I just realized that if I do this: /tmp$ perl bin/eg.pl It works. If I do this: /tmp$ cd bin /tmp/bin$ perl eg.pl I get the 404. Could be this is the desired behavior but as I mentioned it would be nice to get a meaningful error message in the log or on the console. Error 404 Unable to process your query The page you requested is not available Powered by Dancer 1.3011 And nothing is printed to development.log nor the console where eg.pl is running. On Sat, Feb 26, 2011 at 1:35 AM, sawyer x <xsawyerx@gmail.com> wrote:

Hi Brian.

I've written just what Flavio suggest, and it works perfectly. No 404's. Using relative paths.

My steps: 1. go to ~/tmp 2. mkdir "tmpls" 3. inside "tmpls", create "test.tt" with content "your text: <% text %>" 4. inside ~/tmp, create file "eg.pl" with content: use Dancer;

set views => 'tmpls';

get '/' => sub {     template test => { text => 'hi' }; };

dance; --

Run it, go to http://localhost:3000/, et voila! :)

On Sat, Feb 26, 2011 at 2:56 AM, Brian E. Lozier <brian@massassi.com> wrote:

...

Thanks for the information, I'm running into some problems, see below.

On Fri, Feb 25, 2011 at 9:10 AM, Flavio Poletti <polettix@gmail.com> wrote:

...

0. You pay only for what you use:    perl -MDancer -e 'get "/" => sub {return "Hello, World!"}; dance' 1. There seems to be an undocumented configuration feature that lets you specify the base directory for templates:    perl -MDancer -e 'set views => "foo"; get "/" => sub {template "bar"}; dance' (this takes foo/bar.tt instead of views/bar.tt), I wonder if this can be made official and documented.

I can't seem to get this to work.  When I use this "set views" as you suggested or views: in the config file, it sets the "views" config to that dir (say, "templates", and I verified this by Dumping the config hash), but I always get 404.  This is problem #1, when I get a 404 I get no detailed information in the logs whatsoever.  I get nothing in development.log actually.  In this case, I know what the problem is (will say it in a second), but it would be really nice if Dancer would tell me somewhere what the problem is.  404 can mean route not found but apparently also view/template not found.  There should be some way to disambiguate this fact.

The problem is that it's looking in the wrong place for the "templates" directory.  I don't know where it's looking, but it's not looking in appdir/templates.  If I set views => '/full/path/to/templates' it works, but if I use what I intend to be a relative directory I just get 404 error messages.  Setting to app_dir . templates works if I set it in the code, but I can't figure out how to use "appdir" in config.yml (I'd rather set it in config.yml than in code).

This isn't really a big deal.  My real problem is that we have a function called template which looks in the views directory.  This terminology mismatch is disconcerting.  Since most perl modules call everything templates and the function is named template it seems like the files should be in "templates."  However, if we like the "views" terminology we should just name the function "view" instead.

Or figure out what I'm doing wrong with the config :)  I realize this is undocumented behavior and I can't expect it to work.  I'm going to follow the convention and use "views" for now.

...

2. No restriction regarding the project directory name, just try it :-) The normal startup script is a standard Perl program: #!/usr/bin/env perl use Dancer; use WhateverName::YouLike::ForYour::DancerApplication; dance;

Cheers,     Flavio.

On Fri, Feb 25, 2011 at 5:03 PM, Brian E. Lozier <brian@massassi.com> wrote:

...

I'm going to do a test implementation of a dancer web app into an existing project.  I would like to know the minimum files I need to create in order to get it running.  My intention is not to use the scaffolding script to create files as 1) it creates a bunch of files I don't need [but I don't know which ones are strictly required], 2) it creates a directory structure designed to house all my code, but I already have a directory structure [that might not match Dancer's exactly], and 3) I find scaffolding scripts hide a bunch of information that it's really better for me to understand instead of gloss over.  I would essentially like to start from scratch.  If there is not already documentation on this and I get some feedback here, I'll be happy to write a document and submit it back to the list.

I have a couple other questions as well.

1. Is it possible for me to specify the "templates" directory as something other than "views" (we use "template" function in the code, it makes more sense to load it from a "templates" directory instead of a "views" directory)? 2. Is there an in-code restriction that requires me to have the directory name of my project (like "myproject") match the name of the dancer app module (myproject.pm)?  I ask because it's not perlish to have a lower-cased module (like myproject.pm) but I don't want to name my directory MyProject because it's annoying to type.  Generally lower case module names are reserved for pragmas (like warnings, strict, feature, etc.).

Thanks in advance for any help, Brian _______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users

_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users

_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users

* TOP POSTING - WOW! * Looking at Dancer's code your example makes perfectly sense. I also found references to the 'views' setting in Dancer::Introduction, so it seems to be something that has been forgotten in Dancer::Config's documentation. It also seems that you can use the environment variable DANCER_VIEWS. There are multiple problems here, and some go deep into parts that affect completely unrelated features. The best explanation I can think of is that - without any different intervention - by default the views directory is set to "absolute-path-of-directory-of-calling-script"/../views, which is an absolute path. So it's not technically correct to say that it is set to 'views' only, because this lefts out a lot of things! The bottom line is that your best chance to make this work is to use absolute paths, which should work out of the box whatever directory you jump in before calling the instance script. When you don't use absolute paths, the configuration you set is interpreted according to the current working directory, which yields the behaviour you describe. An obvious objection is "why don't we do the Right Thing with non-absolute paths?" and this is where the issue starts touching other parts. Based on my admittedly limited knowledge of Dancer's internals, I would say that this would mean a strong effort on how configurations are handled, e.g. adding a some handler/mangler to act as a proxy, intercept calls to "set views" and provide some magic under the hood. But the question could be turned inside-out: "why do you need non-absolute paths?", i.e. do you really need to relocate your application that frequently? Considering that you can define a separate configuration file for each environment you can think of (the scaffolding program provides you a "development" and a "production", but you can add whatever "staging", "testing", "joking" you want) this seems likely to be a false problem: just set the right absolute paths for each environment. Cheers, Flavio. ps: it's a bit late for me, so I might be overlooking some obvious solution! On Sat, Feb 26, 2011 at 6:56 PM, Brian E. Lozier <brian@massassi.com> wrote:

I have spent a bit more time on this and I posted a project on github that will allow me to demonstrate the more specific issue I am having. https://github.com/saberworks/dancer-test

If you check out that repo you will see this:

. ./config.yml ./logs ./logs/development.log ./bin ./bin/fan.pl ./lib ./lib/Fan ./lib/Fan/Web.pm ./views ./views/layouts ./views/layouts/outer.tt ./views/home.tt

if you start in . and run this:

perl bin/fan.pl

And go to the site it works fine. If you cd to bin/ and then run:

perl fan.pl

And go to the site it works fine.

Please notice that the "views" folder is called "views" but that the "views" configuration directive is not anywhere in code or in config.yml. If you then go to config.yml and uncomment the views: "views" line and repeat the tests, you will notice:

If you start in . and run this:

perl bin/fan.pl

And then go to the site, you get this:

Error 500 Unable to process your query The page you requested is not available Powered by Dancer 1.3011

If you cd to bin/ and then run:

perl fan.pl

And go to the site, you get this:

Error 404 Unable to process your query The page you requested is not available Powered by Dancer 1.3011

And in either of these two error cases there is no indication in development.log or the console window what the error might be.

So other than that, it seems that dancer behaves differently with an implicit "views" directory than it does with an explicit one (even when I'm using the default "views"). If I rename views to templates I believe I am essentially running into the same problem -- if I explicitly set the views directory in my configuration file I am getting these unexpected results.

Thanks for your attention, Brian

On Sat, Feb 26, 2011 at 1:35 AM, sawyer x <xsawyerx@gmail.com> wrote:

...

Hi Brian.

I've written just what Flavio suggest, and it works perfectly. No 404's. Using relative paths.

My steps: 1. go to ~/tmp 2. mkdir "tmpls" 3. inside "tmpls", create "test.tt" with content "your text: <% text %>" 4. inside ~/tmp, create file "eg.pl" with content: use Dancer;

set views => 'tmpls';

get '/' => sub { template test => { text => 'hi' }; };

dance; --

Run it, go to http://localhost:3000/, et voila! :)

On Sat, Feb 26, 2011 at 2:56 AM, Brian E. Lozier <brian@massassi.com> wrote:

...

Thanks for the information, I'm running into some problems, see below.

On Fri, Feb 25, 2011 at 9:10 AM, Flavio Poletti <polettix@gmail.com> wrote:

...

0. You pay only for what you use: perl -MDancer -e 'get "/" => sub {return "Hello, World!"}; dance' 1. There seems to be an undocumented configuration feature that lets

you

...

...

specify the base directory for templates: perl -MDancer -e 'set views => "foo"; get "/" => sub {template "bar"}; dance' (this takes foo/bar.tt instead of views/bar.tt), I wonder if this can be made official and documented.

I can't seem to get this to work. When I use this "set views" as you suggested or views: in the config file, it sets the "views" config to that dir (say, "templates", and I verified this by Dumping the config hash), but I always get 404. This is problem #1, when I get a 404 I get no detailed information in the logs whatsoever. I get nothing in development.log actually. In this case, I know what the problem is (will say it in a second), but it would be really nice if Dancer would tell me somewhere what the problem is. 404 can mean route not found but apparently also view/template not found. There should be some way to disambiguate this fact.

The problem is that it's looking in the wrong place for the "templates" directory. I don't know where it's looking, but it's not looking in appdir/templates. If I set views => '/full/path/to/templates' it works, but if I use what I intend to be a relative directory I just get 404 error messages. Setting to app_dir . templates works if I set it in the code, but I can't figure out how to use "appdir" in config.yml (I'd rather set it in config.yml than in code).

This isn't really a big deal. My real problem is that we have a function called template which looks in the views directory. This terminology mismatch is disconcerting. Since most perl modules call everything templates and the function is named template it seems like the files should be in "templates." However, if we like the "views" terminology we should just name the function "view" instead.

Or figure out what I'm doing wrong with the config :) I realize this is undocumented behavior and I can't expect it to work. I'm going to follow the convention and use "views" for now.

...

2. No restriction regarding the project directory name, just try it :-) The normal startup script is a standard Perl program: #!/usr/bin/env perl use Dancer; use WhateverName::YouLike::ForYour::DancerApplication; dance;

Cheers, Flavio.

On Fri, Feb 25, 2011 at 5:03 PM, Brian E. Lozier <brian@massassi.com> wrote:

...

I'm going to do a test implementation of a dancer web app into an existing project. I would like to know the minimum files I need to create in order to get it running. My intention is not to use the scaffolding script to create files as 1) it creates a bunch of files

I

...

don't need [but I don't know which ones are strictly required], 2) it creates a directory structure designed to house all my code, but I already have a directory structure [that might not match Dancer's exactly], and 3) I find scaffolding scripts hide a bunch of information that it's really better for me to understand instead of gloss over. I would essentially like to start from scratch. If there is not already documentation on this and I get some feedback here, I'll be happy to write a document and submit it back to the list.

I have a couple other questions as well.

1. Is it possible for me to specify the "templates" directory as something other than "views" (we use "template" function in the code, it makes more sense to load it from a "templates" directory instead of a "views" directory)? 2. Is there an in-code restriction that requires me to have the directory name of my project (like "myproject") match the name of the dancer app module (myproject.pm)? I ask because it's not perlish to have a lower-cased module (like myproject.pm) but I don't want to name my directory MyProject because it's annoying to type. Generally lower case module names are reserved for pragmas (like warnings, strict, feature, etc.).

Thanks in advance for any help, Brian _______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users

_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users

_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users

Okay, I spent some time digging into Dancer and figured out what I need to get errors to actually show. First, in config.yml I need: show_errors: 1 This makes it so that if my layout file is not found, Dancer reports correctly that it's not found. However, if a regular template file is not found, the error message is again meaningless. With show_errors: 1, I still get this: Error 404 runtime error Page not found Stack Here is a patch that allows Dancer::Template to return a meaningful error message. I simply removed a line that says, "is the file readable? If not, return;" -- the act of returning nothing is what covers up the real error. The same check does not happen for layouts. With the patch, the error output is now: Runtime Error runtime error '/home/brian/projects/dancer-test/views/home2.tt' is not a regular file at /home/brian/projects/Dancer/lib/Dancer.pm line 223 /home/brian/projects/Dancer/lib/Dancer.pm around line 223 220 my $content; 221 222 if ($view) { 223 $content = Dancer::Template->engine->apply_renderer( $view, $tokens ); 224 if ( !defined $content ) { 225 return Dancer::Error->new( 226 code => 404, Stack https://github.com/saberworks/Dancer/commit/b549e14e95e8ab2be5744b5ab1c613a2... On Sat, Feb 26, 2011 at 7:02 PM, Brian E. Lozier <brian@massassi.com> wrote:

I don't strictly need relative paths.  The question "relative to what?" is a complicated one.  I think the ideal situation would be to have two configuration directives, one for "app_dir" or similar and then all subsequent path-related variables could be relative to that.

I would really like to discuss the handling of errors in Dancer.  I would like to understand why in some cases it gives 404 and in others 500, and ultimately, why it doesn't print something meaningful to the console or to the log file.  If I am running a dancer application in a production environment and users start reporting 404 or 500 errors, how would I go debug this situation?  To me this is far more important than relative/absolute paths for templates.

Thanks again for your attention and explanations.

Brian

On Sat, Feb 26, 2011 at 2:39 PM, Flavio Poletti <polettix@gmail.com> wrote:

...

* TOP POSTING - WOW! * Looking at Dancer's code your example makes perfectly sense. I also found references to the 'views' setting in Dancer::Introduction, so it seems to be something that has been forgotten in Dancer::Config's documentation. It also seems that you can use the environment variable DANCER_VIEWS. There are multiple problems here, and some go deep into parts that affect completely unrelated features. The best explanation I can think of is that - without any different intervention - by default the views directory is set to "absolute-path-of-directory-of-calling-script"/../views, which is an absolute path. So it's not technically correct to say that it is set to 'views' only, because this lefts out a lot of things! The bottom line is that your best chance to make this work is to use absolute paths, which should work out of the box whatever directory you jump in before calling the instance script. When you don't use absolute paths, the configuration you set is interpreted according to the current working directory, which yields the behaviour you describe. An obvious objection is "why don't we do the Right Thing with non-absolute paths?" and this is where the issue starts touching other parts. Based on my admittedly limited knowledge of Dancer's internals, I would say that this would mean a strong effort on how configurations are handled, e.g. adding a some handler/mangler to act as a proxy, intercept calls to "set views" and provide some magic under the hood. But the question could be turned inside-out: "why do you need non-absolute paths?", i.e. do you really need to relocate your application that frequently? Considering that you can define a separate configuration file for each environment you can think of (the scaffolding program provides you a "development" and a "production", but you can add whatever "staging", "testing", "joking" you want) this seems likely to be a false problem: just set the right absolute paths for each environment. Cheers,     Flavio. ps: it's a bit late for me, so I might be overlooking some obvious solution!

On Sat, Feb 26, 2011 at 6:56 PM, Brian E. Lozier <brian@massassi.com> wrote:

...

I have spent a bit more time on this and I posted a project on github that will allow me to demonstrate the more specific issue I am having. https://github.com/saberworks/dancer-test

If you check out that repo you will see this:

. ./config.yml ./logs ./logs/development.log ./bin ./bin/fan.pl ./lib ./lib/Fan ./lib/Fan/Web.pm ./views ./views/layouts ./views/layouts/outer.tt ./views/home.tt

if you start in . and run this:

perl bin/fan.pl

And go to the site it works fine.  If you cd to bin/ and then run:

perl fan.pl

And go to the site it works fine.

Please notice that the "views" folder is called "views" but that the "views" configuration directive is not anywhere in code or in config.yml.  If you then go to config.yml and uncomment the views: "views" line and repeat the tests, you will notice:

If you start in . and run this:

perl bin/fan.pl

And then go to the site, you get this:

Error 500 Unable to process your query The page you requested is not available Powered by Dancer 1.3011

If you cd to bin/ and then run:

perl fan.pl

And go to the site, you get this:

Error 404 Unable to process your query The page you requested is not available Powered by Dancer 1.3011

And in either of these two error cases there is no indication in development.log or the console window what the error might be.

So other than that, it seems that dancer behaves differently with an implicit "views" directory than it does with an explicit one (even when I'm using the default "views").  If I rename views to templates I believe I am essentially running into the same problem -- if I explicitly set the views directory in my configuration file I am getting these unexpected results.

Thanks for your attention, Brian

On Sat, Feb 26, 2011 at 1:35 AM, sawyer x <xsawyerx@gmail.com> wrote:

...

Hi Brian.

I've written just what Flavio suggest, and it works perfectly. No 404's. Using relative paths.

My steps: 1. go to ~/tmp 2. mkdir "tmpls" 3. inside "tmpls", create "test.tt" with content "your text: <% text %>" 4. inside ~/tmp, create file "eg.pl" with content: use Dancer;

set views => 'tmpls';

get '/' => sub {     template test => { text => 'hi' }; };

dance; --

Run it, go to http://localhost:3000/, et voila! :)

On Sat, Feb 26, 2011 at 2:56 AM, Brian E. Lozier <brian@massassi.com> wrote:

...

Thanks for the information, I'm running into some problems, see below.

On Fri, Feb 25, 2011 at 9:10 AM, Flavio Poletti <polettix@gmail.com> wrote:

...

0. You pay only for what you use:    perl -MDancer -e 'get "/" => sub {return "Hello, World!"}; dance' 1. There seems to be an undocumented configuration feature that lets you specify the base directory for templates:    perl -MDancer -e 'set views => "foo"; get "/" => sub {template "bar"}; dance' (this takes foo/bar.tt instead of views/bar.tt), I wonder if this can be made official and documented.

I can't seem to get this to work.  When I use this "set views" as you suggested or views: in the config file, it sets the "views" config to that dir (say, "templates", and I verified this by Dumping the config hash), but I always get 404.  This is problem #1, when I get a 404 I get no detailed information in the logs whatsoever.  I get nothing in development.log actually.  In this case, I know what the problem is (will say it in a second), but it would be really nice if Dancer would tell me somewhere what the problem is.  404 can mean route not found but apparently also view/template not found.  There should be some way to disambiguate this fact.

The problem is that it's looking in the wrong place for the "templates" directory.  I don't know where it's looking, but it's not looking in appdir/templates.  If I set views => '/full/path/to/templates' it works, but if I use what I intend to be a relative directory I just get 404 error messages.  Setting to app_dir . templates works if I set it in the code, but I can't figure out how to use "appdir" in config.yml (I'd rather set it in config.yml than in code).

This isn't really a big deal.  My real problem is that we have a function called template which looks in the views directory.  This terminology mismatch is disconcerting.  Since most perl modules call everything templates and the function is named template it seems like the files should be in "templates."  However, if we like the "views" terminology we should just name the function "view" instead.

Or figure out what I'm doing wrong with the config :)  I realize this is undocumented behavior and I can't expect it to work.  I'm going to follow the convention and use "views" for now.

...

2. No restriction regarding the project directory name, just try it :-) The normal startup script is a standard Perl program: #!/usr/bin/env perl use Dancer; use WhateverName::YouLike::ForYour::DancerApplication; dance;

Cheers,     Flavio.

On Fri, Feb 25, 2011 at 5:03 PM, Brian E. Lozier <brian@massassi.com> wrote: > > I'm going to do a test implementation of a dancer web app into an > existing project.  I would like to know the minimum files I need to > create in order to get it running.  My intention is not to use the > scaffolding script to create files as 1) it creates a bunch of files > I > don't need [but I don't know which ones are strictly required], 2) > it > creates a directory structure designed to house all my code, but I > already have a directory structure [that might not match Dancer's > exactly], and 3) I find scaffolding scripts hide a bunch of > information that it's really better for me to understand instead of > gloss over.  I would essentially like to start from scratch.  If > there > is not already documentation on this and I get some feedback here, > I'll be happy to write a document and submit it back to the list. > > I have a couple other questions as well. > > 1. Is it possible for me to specify the "templates" directory as > something other than "views" (we use "template" function in the > code, > it makes more sense to load it from a "templates" directory instead > of > a "views" directory)? > 2. Is there an in-code restriction that requires me to have the > directory name of my project (like "myproject") match the name of > the > dancer app module (myproject.pm)?  I ask because it's not perlish to > have a lower-cased module (like myproject.pm) but I don't want to > name > my directory MyProject because it's annoying to type.  Generally > lower > case module names are reserved for pragmas (like warnings, strict, > feature, etc.). > > Thanks in advance for any help, > Brian > _______________________________________________ > Dancer-users mailing list > Dancer-users@perldancer.org > http://www.backup-manager.org/cgi-bin/listinfo/dancer-users

_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users

_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users