Great idea and nice plugin ! Thanks On 11 March 2011 02:04, Flavio Poletti <polettix@gmail.com> wrote:
Hi, I just created a module to bridge Dancer's logging mechanism to Log::Log4perl. You can find it at https://github.com/polettix/Dancer-Logger-Log4perl - in the page you'll find pointers to the CPAN package as well (still in developer version, which is a good thing because I just realised that I forgot to include dependencies...). This module should allow you to use Log::Log4perl as usual (both in easy mode and in full-fledged object-oriented mode) or through Dancer's logging interface, whichever you like most. I also added support for Log::Log4perl::Tiny because... ok, it's mine ;-) Feedbacks welcome! Cheers, Flavio.
On Wed, Mar 9, 2011 at 1:14 AM, Brian E. Lozier <brian@massassi.com> wrote:
I'm really looking for a way to share my application's logging mechanism with dancer. Importing dancer logging functions into my existing code causes problems because of commonly-named functions (like params). Having an object-based logger would be nice. When things are encapsulated in objects we don't have to worry about function name collisions. Is there a way for me to instantiate my own logging facility (say, log4perl) and instruct Dancer to use it instead of its own logging mechanism?
On Tue, Mar 8, 2011 at 2:14 PM, Naveed Massjouni <naveedm9@gmail.com> wrote:
On Tue, Mar 8, 2011 at 3:04 PM, Maurice Mengel <mauricemengel@gmail.com> wrote:
Hi!
When I started this mail, I still though that to selectively exclude some dancer functions will NOT solve all problems of this kind. It seems to work in some cases, as with Moose, which I don't use myself. So it is a good next step. But maybe actually it is very close to a generic solution.
But can/should we not also come up with a generic means of how to deal with the naming conflicts?
I ran into this problem with debug and warning which I wanted to override. I wanted to use Dancer's debug in some contexts and in some other context I want my own debug function. At the time there were probably nicer solutions for my problem, but that's a different story. Anyway, I don't want to digress too much.
If we can exclude any Dancer sub, there should be a nice generic mechanism (to be documented in the Cookbook) that allows us also to rename subs in order to solve conflicts and use both. Maybe along these lines:
sub dancer_debug { goto &Dancer::Logger::debug; }
This should work even if debug were exluded, right? And then I could use dancer_debug instead of debug with the same functionality and use my own debug function in other cases. So it would renamed.
Is this generic? Is there a better way for renaming dancer functions/methods/keywords?
best maurice
if ( defined(&Dancer::Logger::debug) ) {
}
You will be able to do: use Dancer qw(!debug); use MyLogger qw(debug); Dancer::debug('blah'); debug('blah');
Is that not good enough? Were you thinking more along the lines of what Sub::Exporter provides? -Naveed
On Tue, Mar 8, 2011 at 8:33 AM, Mr. Puneet Kishor <punk.kish@gmail.com> wrote:
On Mar 8, 2011, at 2:17 AM, franck wrote:
Hi
On Tue, Mar 8, 2011 at 7:40 AM, Flavio Poletti <polettix@gmail.com> wrote: Hi,
first of all you should import with the ":syntax" import option to avoid some collateral effects that should happen only in the main module:
use Dancer ':syntax';
Second, looking at the code the import mechanism is quite bare-bones and does not allow you to perform selective import. Considering that you have control upon the module that needs Dancer, do you think that you can rename your "sub params" in some other way? I think it should be better for you too - having two "params" requires a switch of mental context at each edit file change.
Cheers,
I'm in the process of merging an awesome patch by ironcamel / sawyer / schwern where you will be able to exclude some keywords, and importing groups of keyword (like Dancer ':moose', which will exclude before and after)
This will be available in our next release (probably this week).
franck, please note that 'get' and 'set' conflict with the similarly named methods in PDL [http://pdl.perl.org]. There might be other conflicts as well. This has been causing me quite some grief for a while now.
Flavio.
On Tue, Mar 8, 2011 at 3:43 AM, Brian E. Lozier <brian@massassi.com> wrote: Well I think I hit "send" too soon. The problem is that I have a "params" METHOD already defined in this form class. When I import Dancer it seems to override that method. Is there a way to only import the logging functions and not all the Dancer functions?
Thanks!
On Mon, Mar 7, 2011 at 6:40 PM, Brian E. Lozier <brian@massassi.com> wrote: > I have some modules for form generation and processing that aren't > Dancer classes (in that they don't contain any routes). Inside > these > I'd like to use some of the dancer functions like "params." When I > "use Dancer" at the top of one of these modules I am getting a > really > odd error message. > > runtime error > > Operation "eq": no method found, > left argument in overloaded package Fan::Form::Register, > right argument has no overloaded magic at > /usr/local/lib/perl5/site_perl/5.12.3/Dancer/Request.pm line 177. > > /usr/local/lib/perl5/site_perl/5.12.3/Dancer/Request.pm around line > 177 > > 174 return %{$self->{params}} if wantarray && @_ == 1; > 175 return $self->{params} if @_ == 1; > 176 > 177 if ($source eq 'query') { > 178 return %{$self->{_query_params}} if wantarray; > 179 return $self->{_query_params}; > 180 } > > In my main Dancer class, Fan::Web, I have a route sub that says: > > my $params = params(); > > I then pass this hashref into my form module like this: > > my $form = Fan::Form::Register->new($params); > > If I don't "use Dancer" in the form module, all works well. If I > "use > Dancer;" in the form module I get the error message. I am trying > to > use Dancer so I can use the debug/warning functions. I don't > understand the error message. I have an overloaded "" operator in > the > form class (to return an HTML representation of the form) but I > don't > know how calling the params() function in my main Dancer routes > class > (Fan::Web) and then passing the hashref into my form class can > cause > an error like this. Any thoughts? > > Thanks, > 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
_______________________________________________ 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