- dancer-users - lists.preshweb.co.uk

Can I subclass DP::Authorize::Credentials from a different namespace
by Gurunandan Bhat 14 Dec '10

14 Dec '10

Hi, I want to subclass Dancer::Plugin::Authorize::Credentials but not in the DPAC namespace, but in my App namespace, essentially something that would go like this: package App:Authenticate; use base qw/Dancer::Plugin::Authorize::Credentials/; sub authorize { my ($app, $opts, $username, $passwd) = @_; ..... } 1; I have two questions: 1. Can I do this? 2. If yes, how do I set option parameters in config.yml so that they are passed as a hashref in $opts. Thank you. ----------------------------------------------------------------- dancer does for web frameworks what sqlite did to databases

2 1

named parameters in GET
by Puneet Kishor 12 Dec '10

12 Dec '10

I am having a bit of mental block... is something like this possible? in the browser /foo/bar/?a=blah&b=bork and in the applications get '/foo/:page' => sub { my $page = params->{page}; my $a = params->{a}; my $b = params->{b}; .. } I keep on getting the "void" message. If I change the uri to /foo/bar?a=blah&b=bork (note, the missing trailing / after bar) then the browser itself barfs saying the file wasn't found. -- Puneet Kishor

2 1

Adding quick_insert / quick_update to Dancer::Plugin::Database - design feedback requested
by David Precious 09 Dec '10

09 Dec '10

Hi all, I'm thinking of adding a couple of convenience features to Dancer::Plugin::Database, but I can't seem to decide on a clean interface design, and would appreciate any feedback. I very commonly find myself inserting/updating records in a database, so I'd like to provide quick_insert() and quick_update() keywords which would work something like: # Insert a new row into $table quick_insert($table, { field => 'value', field2 => 'value2' }); # Update the row where the id column is 42: quick_update($table, { id => 42 }, { field => 'newvalue' }); # Maybe also a way to delete rows quickly: quick_delete($table, { id => 42 }); The problem is mostly in supporting multiple database connections. I'm thinking either make quick_insert() and quick_update() accept a hashref of named parameters or a list of positional parameters, so in the simplest case you could use them as per above, and if you're using multiple connections, you could instead say e.g.: quick_insert({ connection => 'development', table => 'tablename', data => { field => 'value', ... }, }); quick_update({ connection => 'development', table => 'tablename', where => { id => 42 }, data => { field => 'new value' }, }); What do you think to that? I'm not particularly keen on it, but it would work. In both cases, you could supply a pre-written WHERE clause as a straight scalar, or a set of values as a hashef. (For most cases, you'd probably just use a hashref of e.g. { keycolumn => 'value' }). The other way I was considering was to allow an optional first param which would be the connection name, so e.g.: # Use the default database details: quick_insert('tablename', { field => 'value' ... }); # Use a different named connection: quick_insert('connectionname', 'tablename', { field => 'value' }); That would work, too, but changing the meaning of positional parameters feels wrong to me... Finally, I'm not sure whether to go with quick_insert / quick_update etc, or use names which make it clearer that they're database-related, like quick_db_update(), or database_quick_update(), or something similar. I'd appreciate anyone's thoughts. Cheers Dave P -- David Precious <davidp(a)preshweb.co.uk> (BIGPRESH) http://blog.preshweb.co.uk/ www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook www.preshweb.co.uk/identica www.lyricsbadger.co.uk "Programming is like sex. One mistake and you have to support it for the rest of your life". (Michael Sinz)

7 12

Re: [Dancer-users] about Dancer
by Alexis Sukrieh 07 Dec '10

07 Dec '10

[ CC'ing to the dancer-users ML as this is of common interest ] Hi, Le 07/12/2010 11:32, metys a écrit : > Hi, > > My name is Łukasz Lewandowski, (or "Metys", easier ;-)) > > I decided to write this mail, because I have few questions/suggestions related to your Dancer framework... > > Before I start, I want to say, that I realy like Dancer (currently, is my number one), but... Glad to see that Dancer fits your needs. > 1. I don't understand, why treat Dancer::Session as a framework "core" functionality (why you put it tnto Dancer.pm), instead of create a plugin? > I can live (but don't agree) with that... That's funny you write about that, because I've wrote an article (unpublished yet, be patient ;) for our Advent Calendar[1] about Dancer internals. In this article I'll explain all the reasons behind the design of Dancer, so I won't detail everything here (don't want to spoil our great advent calendar!). But basically, when I wrote Dancer, I've intetified some common fields in web development that I wanted to be very easily integrated with Dancer. I wanted also to have the possibility to write multiple backends for them, easily, so the CPAN community can extend very quickly our namespace (and that did happen, so I guess I was right on this). That's why the Dancer::Engine strategy wenty into place. You'll have details about that design in my upcomong article entitled "Dancer Internals". So basivally, you have: - The core - Engines - the DSL layer - Plugins Most of the engines are outside of the core, what the core provides is the abstract class real engines must implement. 1: http://advent.perldancer.org/ > 2. I think, Dancer.pm sholud be able to export methods in two ways - all at once (like current ':syntax' tag do), and separately (on demand). > If I could, I would change current @EXPORT to @EXPORT_OK. Why? When we create request handlers ':syntax' is cool, but when we want to create > something more complicated it is inconvenient (for example, if I "use Dancer" I can't use (very natural) method names, like "get"). Of course > I can set all what I need (in most cases config/logger/request/session) as arguments of constructor, but it is not "Dancer" like solution? Of > course there is third method, I can (for example) use Dancer::SharedData, Dancer::Session, Dancer::Logger and get all what I need in the same > way like you do in Dancer.pm, but having the same logic in 2 places is... ugly! :-) The best way I thing would be: > > "use Dancer qw( config logger ... )". You're right on this, and we are aware of that. This is one of the improvement we have planed for 1.4 > 3. Why Dancer::Request "current instance" is stored in SharedData, and Dancer::Session is not? This are both the same "per request" kind? Same as the previous one: we'll do some huge refactoring of the internals for 1.4, this may change as well. You have to know that we put a lot of effort to stabilize the actual version of Dancer into a mature and solid release (1.2xxx). Refactoring is still needed, we're aware of that, but that was more important for us to release 1.2 first. Now that it is out, we can start focusing on this kind of things. Expect it to happen in 2011. > 4. I thing, Dancer ':syntax' should have a&logger method, that returns "current logger" instance. If I want to get it (for example, to pass it as argument somewhere) I have to get it from Dancer::Logger, and this is (once again) not "Dancer" like solution (I think)... Well, Dancer is a DSL, that's why people like it. debugging a web app is of very common use, and I'd rather do in my app "debug", "warning" or "error" rather than issuing: "logger->debug" Basically, that's also why I dared bypassing the Perl culture by ignoring @_ and full OO approach. Agian, that's a key-feature for lots of people that use Dancer. IT's very expressive because of that specific choices. That's part of Dancer's personality, and we should keep it that way. > There is a few more things, but first, I want to know your opinion about this four... You're welcome, I suggest you subscribe to the mailing-list if you have more: http://lists.perldancer.org/cgi-bin/listinfo/dancer-users > > Of course you allways can say: "wtf. get lost" - this does not change anything, and I will still "use Dancer" ;-) > > Once again, "realy cool piece of... code"! Thx You're welcome, stay tuned with the calendar, that article speaking about will detail the things covered in this mail. Regards, -- Alexis Sukrieh

1 0

no logging files
by Joel Roth 07 Dec '10

07 Dec '10

Hi all, I didn't notice how it happened, but after initially seeing some log entries, now I get nothing in there, neither on the server nor on the local machine. - The permissions seem okay. - My config files (below) are also all vanilla. Any ideas would be welcome. I'd rather not be flying blind. :-) Regards, Joel ........... config.yml yout: "main" logger: "file" appname: "danceapp" session: "YAML" template: "template_toolkit" development.yml log: "debug" warnings: 1 show_errors: 1 auto_reload: 1 production.yml warnings: 0 show_errors: 0 route_cache: 1 auto_reload: 0 -- Joel Roth

3 3

login example using before filter
by Joel Roth 05 Dec '10

05 Dec '10

I've had some difficulties with the before filter example provided in Dancer::Introduction. If we pass the information via 'session' rather than 'var' and use 'redirect' instead of 'request->path_info' we get code that more-or-less works as expected: before sub { if (!session('user') and request->path_info !~ m{^/login}) { session requested_path => request->path_info; redirect('/login'); } }; post '/login' => sub { # authenticate credentials session user => params->{user}; my $path = session->{requested_path}; session requested_path => undef; redirect $path }; Here is naive code based on the docs that _doesn't_ work: before sub { if (!session('user') && request->path_info !~ m{^/login}) { var requested_path => request->path_info; request->path_info('/login'); } }; post '/login' => sub { # check credentials session user => params->{user}; my $path = vars->{requested_path}; redirect $path # [1] # request->path_info($path) # [2] }; The first difference is that this 'before' filter causes the login page to show the original URL instead of /login. The second difference is that neither of the rerouting alternatives leads to the desired behavior. [1] results in VOID. [2] results '/initial_requested_path' as display content I'd be interested in understanding how to fix the failed implementation. And I'm also willing to patch the docs to show a complete, successful implementation. Cheers, Joel -- Joel Roth

2 2

dbh->ping causes segmentation fault in D::P::Database
by Иван Бессарабов 04 Dec '10

04 Dec '10

The only thing that stopped me from using dancer in production is the problem that it accidently crashes. Today and yesterday I was experimenting to find out the problem. I have found the solution that fixes the problem, but maybe somebody can find better solution. So. How to reproduce the problem. perl, v5.10.1 Dancer v1.2000 Dancer::Plugin::Database v0.11 DBI v1.615 DBD::mysql v4.007 mysql Ver 14.14 Distrib 5.1.41, for debian-linux-gnu (i486) using readline 6.1 Then create simple application ("dancer -a MyDb") in config write db connection info: plugins: Database: driver: 'mysql' database: 'sample' host: 'localhost' username: 'uname' password: 'secret' connection_check_threshold: 1 dbi_params: RaiseError: 1 AutoCommit: 1 on_connect_do: ["SET NAMES 'utf8'", "SET CHARACTER SET 'utf8'" ] In MyDb.pm write something like: my $sth = database->prepare('SELECT count(id) AS c FROM t1'); $sth->execute; $v->{count} = $sth->fetchrow_hashref->{c}; Then start app by "./bin/app.pl", access the page, then restart mysql and try to access the same route again. The app is not responding and in log I get this: [16248] core @0.028376> [hit #8] trying to match `/' against /^\/$/ in /usr/local/share/perl/5.10.1/Dancer/Route.pm l. 74 [16248] core @0.028638> [hit #8] --> got 1 in /usr/local/share/perl/5.10.1/Dancer/Route.pm l. 80 ./start: line 1: 16248 Segmentation fault ./bin/app.pl After investigating I have found that the app is crashed by line "my $result = $dbh->ping" in Dancer/Plugin/Database.pm In the internet I have found the solution http://www.nntp.perl.org/group/perl.dbi.users/2008/07/msg33044.html I've added one line to my config file and it stopped crashing. Here is the fragment of config.yml that works without crahses: dbi_params: mysql_auto_reconnect: 0 RaiseError: 1 AutoCommit: 1

2 2

redirect in post route appears to fail
by Joel Roth 04 Dec '10

04 Dec '10

Hi again, Stumbling web newbie seeks scarred veteran for guidance. (Failing which he is considering some self-scarring.) I just install 1.2001 from CPAN. Here are my routes: get '/redirect' => sub { redirect '/welcome' }; post '/login' => sub { redirect '/welcome' }; get '/login' => sub { render_as_markdown('login') }; And here are the results I get: http://host/redirect -> welcome page http://host/login -> login page with CGI form Submit login form -> login page with params in URL I would expect the pressing 'Submit' to trigger the 'post' route and redirect to 'welcome'. Can anyone suggest how I might get that behavior? Or what I may be misunderstanding. More details.... The login page has a form: <form> Username: <input type="text" name="user" /><br /> Password: <input type="password" name="pass" /><br /> <input type="submit" value="Submit" /> </form> The full HTML source to the login page is here: http://pastebin.com/e7QQJ4vw I think there may be something *else* wrong. The app doesn't produce any logs (even from a die) although development.log appears in lsof output for the process. Thanks, Joel -- Joel Roth

2 2

Template
by sigzero 03 Dec '10

03 Dec '10

I just want to suggest Template::Tiny as an alternative to Template::Toolkit. For most of the templating needs it gives you want you want with less dependencies (lighter) and better memory usage. I love the advent stuff too. Thanks for it all! Robert

4 5

URL rewrite, comments?
by Joel Roth 02 Dec '10

02 Dec '10

Hi all, Here is an update on a newbie dancing pilgrim's progress, through the shoals of mod_rewrite. Starting with the rewrite rules in Dancer::Deployment, I've been trying to get the behavior I want from my website URLs. I've got a solution (below) that allows access control using .htaccess. In future I expect to handle everything through Dancer. I guess I'd like some feedback, how to do it better. For example, I think RewriteBase might be a more concise way to introduce dispatch.cgi... if I could only get it right. Thanks for any thoughts on this. Joel # BEGIN htaccess # # dispatch.cgi launches dancer app RewriteEngine On # Dancer gets null path requests # example.org -> example.org/dispatch.cgi # example.org/ -> example.org/dispatch.cgi RewriteRule ^.{0,1}$ dispatch.cgi [L] # Pass existing file or directory links to apache # example.org/audio # example.org/audio/test.mp3 RewriteCond %{REQUEST_FILENAME} -d [OR] RewriteCond %{REQUEST_FILENAME} -f RewriteRule .* - [L] # Dancer gets everything else RewriteRule (.+) dispatch.cgi/$1 # END htaccess -- Joel Roth

1 0