[Dancer-users] How to use dancer functions in other modules
Brian E. Lozier
brian at massassi.com
Mon Mar 14 15:20:23 CET 2011
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 at 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 at 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 at 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 at gmail.com>
>>> wrote:
>>> > On Tue, Mar 8, 2011 at 3:04 PM, Maurice Mengel
>>> > <mauricemengel at 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 at 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 at 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 at 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 at 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 at perldancer.org
>>> >>> http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
>>> >>>
>>> >> _______________________________________________
>>> >> Dancer-users mailing list
>>> >> Dancer-users at perldancer.org
>>> >> http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
>>> >>
>>> > _______________________________________________
>>> > Dancer-users mailing list
>>> > Dancer-users at perldancer.org
>>> > http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
>>> >
>>> _______________________________________________
>>> Dancer-users mailing list
>>> Dancer-users at perldancer.org
>>> http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
>>
>>
>> _______________________________________________
>> Dancer-users mailing list
>> Dancer-users at perldancer.org
>> http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
>>
>
>
> _______________________________________________
> Dancer-users mailing list
> Dancer-users at perldancer.org
> http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
>
>
More information about the Dancer-users
mailing list