The latest version of Task::Dancer can't install because the Log4Perl plugin is still in development mode (as of last night) (so CPAN won't load it) and I also got errors about Dancer::Plugin::MPD. On Fri, Mar 11, 2011 at 2:16 AM, sawyer x <xsawyerx@gmail.com> wrote:
Already saw and liked!
Please to be added to Task::Dancer. :)
On Fri, Mar 11, 2011 at 3:04 AM, 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
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users