[Dancer-users] Minimum code required to get Dancer up and running?
Brian E. Lozier
brian at massassi.com
Sun Feb 27 19:22:03 CET 2011
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/b549e14e95e8ab2be5744b5ab1c613a23aa1e148
On Sat, Feb 26, 2011 at 7:02 PM, Brian E. Lozier <brian at 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 at 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 at 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 at 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 at 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 at 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 at 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 at perldancer.org
>>> >> >> http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
>>> >> >
>>> >> >
>>> >> > _______________________________________________
>>> >> > Dancer-users mailing list
>>> >> > Dancer-users at perldancer.org
>>> >> > http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
>>> >> >
>>> >> >
>>> >> _______________________________________________
>>> >> Dancer-users mailing list
>>> >> Dancer-users at perldancer.org
>>> >> http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
>>> >
>>> >
>>
>>
>
More information about the Dancer-users
mailing list