[Dancer-users] How to use dancer functions in other modules
Flavio Poletti
polettix at gmail.com
Fri Mar 11 02:04:19 CET 2011
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.backup-manager.org/pipermail/dancer-users/attachments/20110311/c506a285/attachment.html>
More information about the Dancer-users
mailing list