Ouch! At the very last I got some feedback from CPANTESTERS, I plan to upload a "stable" release later this evening. Cheers, Flavio. On Mon, Mar 14, 2011 at 3:20 PM, Brian E. Lozier <brian@massassi.com> wrote:
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.
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
On Fri, Mar 11, 2011 at 2:16 AM, sawyer x <xsawyerx@gmail.com> wrote: 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