How to use dancer functions in other modules
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
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
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, 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
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).
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
-- franck cuny http://lumberjaph.net - http://github.com/franckcuny
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 ..
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) ) { } 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
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
On Mar 8, 2011, at 5:14 PM, Naveed Massjouni wrote:
You will be able to do: use Dancer qw(!debug); use MyLogger qw(debug); Dancer::debug('blah'); debug('blah');
Is that not good enough?
the above would be great from my perspective. Puneet.
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
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
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
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
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
Hi, I just uploaded version 0.8.0 to CPAN. I forgot to add in the Changes file that I added some more examples in the documentation, the code is the same as 0.7.0_03. Cheers, Flavio. On Mon, Mar 14, 2011 at 6:48 PM, Flavio Poletti <polettix@gmail.com> wrote:
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
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
participants (8)
-
Brian E. Lozier -
damien krotkine -
Flavio Poletti -
franck -
Maurice Mengel -
Mr. Puneet Kishor -
Naveed Massjouni -
sawyer x