Dancer2 - feature change request
Since dancer2 is on the way, I thought I'd be cheeky and suggest a slight change in functionality (rather than wait until dancer3). Does anyone (particularly core devs of course) have any strong opinions on the following? At the moment, the logging levels are exposed directly (debug, warning, error). All the major logging modules seem to expose a single object (Log::Log4perl, Log::Dispatch, Log::Any etc). Doing similar would make logging more consistent across dancer and my non-web modules. To be explicit, I'm suggesting this: debug("current id = $id") would become: log->debug("current id = $id") It's a purely cosmetic change at one level, but it does: 1. Reduce namespace pollution 2. Allow for alternative log-levels I actually think the printf-style functionality of Log::Any is worth stealing too. It lets you do things like: log->debugf("user %d has fields %s", $user_id, $user_hashref) With $user_hashref being automatically piped through Data::Dumper -- Richard Huxton Archonet Ltd
On Fri, Oct 21, 2011 at 11:55 AM, Richard Huxton <dev@archonet.com> wrote:
At the moment, the logging levels are exposed directly (debug, warning, error). All the major logging modules seem to expose a single object (Log::Log4perl, Log::Dispatch, Log::Any etc). Doing similar would make logging more consistent across dancer and my non-web modules.
To be explicit, I'm suggesting this: debug("current id = $id") would become: log->debug("current id = $id")
It's a purely cosmetic change at one level, but it does: 1. Reduce namespace pollution 2. Allow for alternative log-levels
Namespace pollution is - for good or bad - what Dancer is about; otherwise, there would be no DSL. I like the idea of having one-off functions for logging as for anything else, even if I like Log::Log4perl and I usually avoid Dancer's internal debugging. IMHO your proposal should go on the Plugin side (e.g. Dancer::Plugin::Log::Log4perl)
I actually think the printf-style functionality of Log::Any is worth stealing too. It lets you do things like: log->debugf("user %d has fields %s", $user_id, $user_hashref) With $user_hashref being automatically piped through Data::Dumper
I like the idea of the "-f", but this would probably bloat and pollute the namespace. Again... this would be a nice plugin :-)
On Fri, Oct 21, 2011 at 10:09 AM, Flavio Poletti <polettix@gmail.com> wrote:
On Fri, Oct 21, 2011 at 11:55 AM, Richard Huxton <dev@archonet.com> wrote:
At the moment, the logging levels are exposed directly (debug, warning, error). All the major logging modules seem to expose a single object (Log::Log4perl, Log::Dispatch, Log::Any etc). Doing similar would make logging more consistent across dancer and my non-web modules.
To be explicit, I'm suggesting this: debug("current id = $id") would become: log->debug("current id = $id")
It's a purely cosmetic change at one level, but it does: 1. Reduce namespace pollution 2. Allow for alternative log-levels
Namespace pollution is - for good or bad - what Dancer is about; otherwise, there would be no DSL. I like the idea of having one-off functions for logging as for anything else, even if I like Log::Log4perl and I usually avoid Dancer's internal debugging. IMHO your proposal should go on the Plugin side (e.g. Dancer::Plugin::Log::Log4perl)
Everyone keeps talking about "DSL" -- what is that? Last time I used DSL it was for getting internet access through the phone company. (and don't use google to search for "define dsl" at work, you don't want to see the urban dictionary result)
I actually think the printf-style functionality of Log::Any is worth stealing too. It lets you do things like: log->debugf("user %d has fields %s", $user_id, $user_hashref) With $user_hashref being automatically piped through Data::Dumper
I like the idea of the "-f", but this would probably bloat and pollute the namespace. Again... this would be a nice plugin :-)
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
On Oct 21, 2011, at 12:21 PM, Brian E. Lozier wrote:
On Fri, Oct 21, 2011 at 10:09 AM, Flavio Poletti <polettix@gmail.com> wrote:
On Fri, Oct 21, 2011 at 11:55 AM, Richard Huxton <dev@archonet.com> wrote:
At the moment, the logging levels are exposed directly (debug, warning, error). All the major logging modules seem to expose a single object (Log::Log4perl, Log::Dispatch, Log::Any etc). Doing similar would make logging more consistent across dancer and my non-web modules.
To be explicit, I'm suggesting this: debug("current id = $id") would become: log->debug("current id = $id")
It's a purely cosmetic change at one level, but it does: 1. Reduce namespace pollution 2. Allow for alternative log-levels
Namespace pollution is - for good or bad - what Dancer is about; otherwise, there would be no DSL. I like the idea of having one-off functions for logging as for anything else, even if I like Log::Log4perl and I usually avoid Dancer's internal debugging. IMHO your proposal should go on the Plugin side (e.g. Dancer::Plugin::Log::Log4perl)
Everyone keeps talking about "DSL" -- what is that? Last time I used DSL it was for getting internet access through the phone company. (and don't use google to search for "define dsl" at work, you don't want to see the urban dictionary result)
Domain Specific Language. Besides, that I am with you... have no idea what that means. Puneet.
On Fri, Oct 21, 2011 at 7:23 PM, Puneet Kishor <punk.kish@gmail.com> wrote:
On Oct 21, 2011, at 12:21 PM, Brian E. Lozier wrote:
On Fri, Oct 21, 2011 at 10:09 AM, Flavio Poletti <polettix@gmail.com> wrote:
On Fri, Oct 21, 2011 at 11:55 AM, Richard Huxton <dev@archonet.com> wrote:
At the moment, the logging levels are exposed directly (debug, warning, error). All the major logging modules seem to expose a single object (Log::Log4perl, Log::Dispatch, Log::Any etc). Doing similar would make logging more consistent across dancer and my non-web modules.
To be explicit, I'm suggesting this: debug("current id = $id") would become: log->debug("current id = $id")
It's a purely cosmetic change at one level, but it does: 1. Reduce namespace pollution 2. Allow for alternative log-levels
Namespace pollution is - for good or bad - what Dancer is about; otherwise, there would be no DSL. I like the idea of having one-off functions for logging as for anything else, even if I like Log::Log4perl and I usually avoid Dancer's internal debugging. IMHO your proposal should go on the Plugin side (e.g. Dancer::Plugin::Log::Log4perl)
Everyone keeps talking about "DSL" -- what is that? Last time I used DSL it was for getting internet access through the phone company. (and don't use google to search for "define dsl" at work, you don't want to see the urban dictionary result)
Domain Specific Language. Besides, that I am with you... have no idea what that means.
The whole "get/post/template/whatever" stuff that Dancer provide form a language that is specific to creating web applications, i.e. specific to the particular "domain" we're talking about. http://en.wikipedia.org/wiki/Domain-specific_language can be more insightful: "In software development <http://en.wikipedia.org/wiki/Software_development> and domain engineering <http://en.wikipedia.org/wiki/Domain_engineering>, a *domain-specific language* (*DSL*) is a programming language<http://en.wikipedia.org/wiki/Programming_language> or specification language<http://en.wikipedia.org/wiki/Specification_language>dedicated to a particular problem domain, a particular problem representation technique, and/or a particular solution technique."
On Oct 21, 2011, at 12:21 PM, Brian E. Lozier wrote:
and don't use google to search for "define dsl" at work, you don't want to see the urban dictionary result)
Great! Thanks!! Telling us not to do it at work was a sure-fire way to make me do it. Thankfully the first definition was "Deep scattering layer."
On Fri, Oct 21, 2011 at 5:55 AM, Richard Huxton <dev@archonet.com> wrote:
Since dancer2 is on the way, I thought I'd be cheeky and suggest a slight change in functionality (rather than wait until dancer3). Does anyone (particularly core devs of course) have any strong opinions on the following?
At the moment, the logging levels are exposed directly (debug, warning, error). All the major logging modules seem to expose a single object (Log::Log4perl, Log::Dispatch, Log::Any etc). Doing similar would make logging more consistent across dancer and my non-web modules.
To be explicit, I'm suggesting this: debug("current id = $id") would become: log->debug("current id = $id")
It's a purely cosmetic change at one level, but it does: 1. Reduce namespace pollution 2. Allow for alternative log-levels
I actually think the printf-style functionality of Log::Any is worth stealing too. It lets you do things like: log->debugf("user %d has fields %s", $user_id, $user_hashref) With $user_hashref being automatically piped through Data::Dumper
-- Richard Huxton Archonet Ltd
I really like your suggestion. Mainly because I wish send_error() was error(). Writing return error(...); is much more natural than return send_error(...); Though it is probably too late to change that now. I know ambs/dams? has a branch for making send_error do call stack magic to solve that. -Naveed
Le 21 oct. 2011 à 20:23, Naveed Massjouni <naveedm9@gmail.com> a écrit :
On Fri, Oct 21, 2011 at 5:55 AM, Richard Huxton <dev@archonet.com> wrote:
Since dancer2 is on the way, I thought I'd be cheeky and suggest a slight change in functionality (rather than wait until dancer3). Does anyone (particularly core devs of course) have any strong opinions on the following?
At the moment, the logging levels are exposed directly (debug, warning, error). All the major logging modules seem to expose a single object (Log::Log4perl, Log::Dispatch, Log::Any etc). Doing similar would make logging more consistent across dancer and my non-web modules.
To be explicit, I'm suggesting this: debug("current id = $id") would become: log->debug("current id = $id")
It's a purely cosmetic change at one level, but it does: 1. Reduce namespace pollution 2. Allow for alternative log-levels
I actually think the printf-style functionality of Log::Any is worth stealing too. It lets you do things like: log->debugf("user %d has fields %s", $user_id, $user_hashref) With $user_hashref being automatically piped through Data::Dumper
-- Richard Huxton Archonet Ltd
I really like your suggestion. Mainly because I wish send_error() was error(). Writing return error(...); is much more natural than return send_error(...); Though it is probably too late to change that now. I know ambs/dams? has a branch for making send_error do call stack magic to solve that.
Indeed it's a PR ready for merging. It just need some review from other core devs ( hint ! hint ! ). Come on guys, just reply "approved" :)
Richard Huxton wrote, On 10/21/11 05:55:
Since dancer2 is on the way, I thought I'd be cheeky and suggest a slight change in functionality (rather than wait until dancer3). Does anyone (particularly core devs of course) have any strong opinions on the following?
While we're at the topic of Dancer2 requests... Would it be possible to make "croak" work properly from within Dancer2 ? At the moment, "croak" will show a stack-call coming from "Route.pm", and I would like to be able to have it point to my actual routing function (if that's somehow possible with un-named code refs and such). Simple contrived example: ======= sub foobar { croak "Something bad happened..."; } get '/login' => sub { foobar(); }; ======== The croaked messages appears from: =========== Something bad happened... at /usr/local/share/perl/5.12.4/Dancer/Route.pm line 240 =========== And the stack-track is: ========= main in ./bin/app.pl l. 4 Dancer in /usr/local/share/perl/5.12.4/Dancer.pm l. 367 Dancer::Handler in /usr/local/share/perl/5.12.4/Dancer/Handler.pm l. 188 Dancer::Handler::Standalone in /usr/local/share/perl/5.12.4/Dancer/Handler/Standalone.pm l. 36 HTTP::Server::Simple in /usr/local/share/perl/5.12.4/HTTP/Server/Simple.pm l. 271 HTTP::Server::Simple in /usr/local/share/perl/5.12.4/HTTP/Server/Simple.pm l. 307 HTTP::Server::Simple in /usr/local/share/perl/5.12.4/HTTP/Server/Simple.pm l. 402 HTTP::Server::Simple::PSGI in /usr/local/share/perl/5.12.4/HTTP/Server/Simple/PSGI.pm l. 103 HTTP::Server::Simple::PSGI in /usr/local/share/perl/5.12.4/HTTP/Server/Simple/PSGI.pm l. 103 Dancer::Handler in /usr/local/share/perl/5.12.4/Dancer/Handler.pm l. 111 Dancer::Handler in /usr/local/share/perl/5.12.4/Dancer/Handler.pm l. 72 Dancer::Handler in /usr/local/share/perl/5.12.4/Dancer/Handler.pm l. 93 Dancer::Object in /usr/local/share/perl/5.12.4/Dancer/Object.pm l. 15 Dancer::Error in /usr/local/share/perl/5.12.4/Dancer/Error.pm l. 36 Dancer::Error in /usr/local/share/perl/5.12.4/Dancer/Error.pm l. 254 ========= Which makes it hard to debug... So currently, all my subs use "die" instead of "croak", but this doesn't seem right (and also doesn't work with 3rd-party code that uses croak). Comments are welcomed, -gordon
Le 21 oct. 2011 à 21:18, Assaf Gordon <gordon@cshl.edu> a écrit :
Richard Huxton wrote, On 10/21/11 05:55:
Since dancer2 is on the way, I thought I'd be cheeky and suggest a slight change in functionality (rather than wait until dancer3). Does anyone (particularly core devs of course) have any strong opinions on the following?
While we're at the topic of Dancer2 requests...
Would it be possible to make "croak" work properly from within Dancer2 ? At the moment, "croak" will show a stack-call coming from "Route.pm", and I would like to be able to have it point to my actual routing function (if that's somehow possible with un-named code refs and such).
I have taken care of that while refactoring the Dancer exceptions. Could you try the topic/exceptions3 branch from github? I've stolen the Carp mechanism and Replaced all croaks by Dancer Exceptions. Verbosity of the stack trace can be setup with $Dancer::Exception::verbose. So when that branch is merged, it'll be fixed in dancer 1 :) dams
Simple contrived example: ======= sub foobar { croak "Something bad happened..."; }
get '/login' => sub { foobar(); }; ========
The croaked messages appears from: =========== Something bad happened... at /usr/local/share/perl/5.12.4/Dancer/ Route.pm line 240 ===========
And the stack-track is: ========= main in ./bin/app.pl l. 4 Dancer in /usr/local/share/perl/5.12.4/Dancer.pm l. 367 Dancer::Handler in /usr/local/share/perl/5.12.4/Dancer/Handler.pm l. 188 Dancer::Handler::Standalone in /usr/local/share/perl/5.12.4/Dancer/ Handler/Standalone.pm l. 36 HTTP::Server::Simple in /usr/local/share/perl/5.12.4/HTTP/Server/ Simple.pm l. 271 HTTP::Server::Simple in /usr/local/share/perl/5.12.4/HTTP/Server/ Simple.pm l. 307 HTTP::Server::Simple in /usr/local/share/perl/5.12.4/HTTP/Server/ Simple.pm l. 402 HTTP::Server::Simple::PSGI in /usr/local/share/perl/5.12.4/HTTP/ Server/Simple/PSGI.pm l. 103 HTTP::Server::Simple::PSGI in /usr/local/share/perl/5.12.4/HTTP/ Server/Simple/PSGI.pm l. 103 Dancer::Handler in /usr/local/share/perl/5.12.4/Dancer/Handler.pm l. 111 Dancer::Handler in /usr/local/share/perl/5.12.4/Dancer/Handler.pm l. 72 Dancer::Handler in /usr/local/share/perl/5.12.4/Dancer/Handler.pm l. 93 Dancer::Object in /usr/local/share/perl/5.12.4/Dancer/Object.pm l. 15 Dancer::Error in /usr/local/share/perl/5.12.4/Dancer/Error.pm l. 36 Dancer::Error in /usr/local/share/perl/5.12.4/Dancer/Error.pm l. 254 ========= Which makes it hard to debug...
So currently, all my subs use "die" instead of "croak", but this doesn't seem right (and also doesn't work with 3rd-party code that uses croak).
Comments are welcomed, -gordon
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
Hi Damien, damien krotkine wrote, On 10/21/11 15:42:
Le 21 oct. 2011 à 21:18, Assaf Gordon <gordon@cshl.edu> a écrit :
Would it be possible to make "croak" work properly from within Dancer2 ?
I have taken care of that while refactoring the Dancer exceptions. Could you try the topic/exceptions3 branch from github? I've stolen the Carp mechanism and Replaced all croaks by Dancer Exceptions. Verbosity of the stack trace can be setup with $Dancer::Exception::verbose.
I'm not exactly sure which/what to try, and pointers will be appreciated. I did clone from "https://github.com/sukria/Dancer/", then switched to "topics/exceptions3" with: $ git checkout -b topic/exceptions3 remotes/origin/topic/exceptions3 and re-run my application with this version of Dancer - but it did not improve the "croak" behavior. regards, -gordon
Le 21 oct. 2011 à 22:10, Assaf Gordon <gordon@cshl.edu> a écrit :
Hi Damien,
damien krotkine wrote, On 10/21/11 15:42:
Le 21 oct. 2011 à 21:18, Assaf Gordon <gordon@cshl.edu> a écrit :
Would it be possible to make "croak" work properly from within Dancer2 ?
I have taken care of that while refactoring the Dancer exceptions. Could you try the topic/exceptions3 branch from github? I've stolen the Carp mechanism and Replaced all croaks by Dancer Exceptions. Verbosity of the stack trace can be setup with $Dancer::Exception::verbose.
I'm not exactly sure which/what to try, and pointers will be appreciated.
I did clone from "https://github.com/sukria/Dancer/", then switched to "topics/exceptions3" with: $ git checkout -b topic/exceptions3 remotes/origin/topic/exceptions3
Yes that's what I meant, you got it right :)
and re-run my application with this version of Dancer - but it did not improve the "croak" behavior.
Aww damned, I thought it would fix it. It's strange because I think I tested this exact behaviour. I must have missed something. I'll fix the code and update the branch, but that won't happen before 10 days. The code adds Dancer in the Carp black list, maybe all Dancer::* should be added too ...
regards, -gordon
On Fri, Oct 21, 2011 at 4:20 PM, damien krotkine <dkrotkine@gmail.com> wrote:
Le 21 oct. 2011 à 22:10, Assaf Gordon <gordon@cshl.edu> a écrit :
Hi Damien,
damien krotkine wrote, On 10/21/11 15:42:
Le 21 oct. 2011 à 21:18, Assaf Gordon <gordon@cshl.edu> a écrit :
Would it be possible to make "croak" work properly from within Dancer2 ?
I have taken care of that while refactoring the Dancer exceptions. Could you try the topic/exceptions3 branch from github? I've stolen the Carp mechanism and Replaced all croaks by Dancer Exceptions. Verbosity of the stack trace can be setup with $Dancer::Exception::verbose.
I'm not exactly sure which/what to try, and pointers will be appreciated.
I did clone from "https://github.com/sukria/Dancer/", then switched to "topics/exceptions3" with: $ git checkout -b topic/exceptions3 remotes/origin/topic/exceptions3
Yes that's what I meant, you got it right :)
and re-run my application with this version of Dancer - but it did not improve the "croak" behavior.
Aww damned, I thought it would fix it. It's strange because I think I tested this exact behaviour. I must have missed something. I'll fix the code and update the branch, but that won't happen before 10 days. The code adds Dancer in the Carp black list, maybe all Dancer::* should be added too ...
You should think carefully about including Dancer::Plugin::* in the black list. I can think of situations when you would want to skip those, and also when you wouldn't. -Naveed
regards, -gordon
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
participants (7)
-
Assaf Gordon -
Brian E. Lozier -
damien krotkine -
Flavio Poletti -
Naveed Massjouni -
Puneet Kishor -
Richard Huxton