Is there a method/feature to write auto-start subroutine/method for all available Mojolicious routes ?
Maybe an automatic helper, but I don't know how to do it yet.
I think this is useful especially to initialize database connection $self->{dbh} for nearly every available routes, ... so I can write like this:
helper DB => sub { state $dbh = Database->new };
get '/' => sub {
my $self = shift;
//$self->{dbh} // is automatically initialized & shared
};
get '/another_route' => sub {
my $self = shift;
//$self->{dbh} // also initialized & shared
};
instead of:
get '/' => sub {
my $self = shift;
$self->{dbh} = init_db();
};
get '/another_route' => sub {
my $self = shift;
$self->{dbh} = init_db();
};
P.S: I'm using Mojolicious:Lite, Perl 5.16, SQLite3
I'm not 100% sure I understand your question, helper does almost exactly what you want, but you shouldn't be using the object's hash. Here is how you would use your code:
helper db => sub { state $dbh = Database->new };
get '/' => sub {
my $self = shift;
$self->db->do_somthing();
};
get '/another_route' => sub {
my $self = shift;
my $dbh = $self->db;
...
};
helper methods are available for use by all controllers, templates and the main app.
Related
I'm trying to implement a dispatch table which calls functions inside a Perl module. I know how to implement dispatch tables generally, but I can't seem to get it right when referencing an object method from within $self. Maybe I haven't Googled enough, but so far, the right syntax is elusive.
I have traced the parameters though the calls, and I know what is happening -- the function references are not receiving a reference to $self as their first parameter. This is what I currently have inside $self. I believe I copied this over properly; if I made a mistake and it doesn't run, I apologize.
package MyRefHashTest;
use strict;
use warnings;
sub new {
my $class = shift;
my $self = {
DISPATCH => {
ONE => \&funcOne,
TWO => \&funcTwo,
THREE => \&funcThree,
FOUR => \&funcFour
}
};
bless $self, $class;
return $self;
}
sub funcOne {
my ($self, $param) = #_;
print "func1 $param \n";
}
sub funcTwo {
my ($self, $param) = #_;
print "func2 $param \n";
}
sub funcThree {
my ($self, $param) = #_;
print "func3 $param \n";
}
sub funcFour {
my ($self, $param) = #_;
print "func4 $param \n";
}
sub runTesting {
my ($self, $type) = #_;
($self->{DISPATCH}{$type} || sub {})->("string");
}
1;
# To Test:
$test = MyRefHashTest->new;
$test->runTesting("ONE");
$test->runTesting("TWO");
$test->runTesting("THREE");
$test->runTesting("FOUR");
The actual output I get is that $param is undefined in the function calls from the dispatch table, when it should not be. This is how I know that the references to $self are not where they should be. The functions think that $type is $self.
I have tried editing the hash table references so they look like \$self->functionName, but that only results in a compilation error for $self not being properly defined on that line.
Can anyone guide me to the right syntax for this, please?
Thanks!
EDIT: After much more work, I finally found a solution. It's some very interesting syntax, a lot more complicated than I thought. Essentially, I'm building the hash from the inside out:
my $self = {
DISPATCH => undef
};
$self->{DISPATCH} = {
ONE => sub { $self->funcOne(#_); },
TWO => sub { $self->funcTwo(#_); },
THREE => sub { $self->funcThree(#_); },
FOUR => sub { $self->funcFour(#_); }
};
It works, but it seems like a lot of hassle for what it is. If anyone knows of an easier way to do this, I would still be very interested in it. If there isn't an easier way, on the other hand, I hope this can help somebody.
What follows are four approaches for implementing a method-based dispatch table. The differences explained afterwards.
my %DISPATCH = (
ONE => \&funcOne,
TWO => \&funcTwo,
THREE => \&funcThree,
FOUR => \&funcFour,
);
sub runTesting {
my ($self, $type) = #_;
my $method = $DISPATCH{$type};
return $self->$method("string");
}
or
my %DISPATCH = (
ONE => __PACKAGE__->can('funcOne'),
TWO => __PACKAGE__->can('funcTwo'),
THREE => __PACKAGE__->can('funcThree'),
FOUR => __PACKAGE__->can('funcFour'),
);
sub runTesting {
my ($self, $type) = #_;
my $method = $DISPATCH{$type};
return $self->$method("string");
}
or
my %DISPATCH = (
ONE => 'funcOne',
TWO => 'funcTwo',
THREE => 'funcThree',
FOUR => 'funcFour',
);
sub runTesting {
my ($self, $type) = #_;
my $method_name = $DISPATCH{$type};
return $self->$method_name("string");
}
or
my %DISPATCH = (
ONE => sub { shift->funcOne(#_) },
TWO => sub { shift->funcTwo(#_) },
THREE => sub { shift->funcThree(#_) },
FOUR => sub { shift->funcFour(#_) },
);
sub runTesting {
my ($self, $type) = #_;
my $cb = $DISPATCH{$type};
return $cb->($self, "string");
}
All four approaches allow the methods to be defined in the same class.
The last three approaches allow the methods to be defined in a superclass as well.
The last two approaches allow a subclass to provide or override the method as well. These are your best options.
How about passing in $self in the dynamic dispatch method:
sub runTesting {
my ($self, $type) = #_;
($self->{DISPATCH}{$type} || sub {})->($self,"string");
^^^^^
}
I believe the problem is that you are invoking the methods as plain functions and not object methods.
Given a syntax like
$c->routes->get($path)->to("$controller#$sub");
I would like to know which sub $controller#$sub resolves to on dispatch. Is there a simple method to get the ref of the sub? You can hard-set ->namespaces() so I assume it's not always as simple as $controller::$sub because you could have namespace::$controller::$sub.
I could not find a way to do this using the api, but there is a private method _class() that will give the controller object that contains the sub. Here is an example:
./lib/MyApp/Controller/Foo.pm:
package MyApp::Controller::Foo;
use Mojo::Base 'Mojolicious::Controller';
sub welcome {
my $self = shift;
$self->render(text => 'Hello there.');
}
1;
./myapp.pl:
use strict;
use warnings;
use Mojolicious::Lite;
use lib './lib';
get '/' => sub {
my $c = shift;
$c->render(text => 'Hello World!');
};
my $namespaces = app->routes->namespaces;
push #$namespaces, 'MyApp::Controller';
app->routes->get('/welcome')->to('foo#welcome');
app->hook(
before_dispatch => sub {
my $c = shift;
my $field = { action => "welcome", controller => "foo" };
my $obj = $c->app->routes->_class( $c, $field );
my $method = $field->{action};
my $subref = sub { $obj->$method( #_ ) };
}
);
app->start;
I have an existing application (my website) that I'm doing some code tidying in, and the tidy up is following the same sort of idea as the Mojo::Pg example here, with separate model and controller files to keep things defined. My site accesses both Flickr and Last.fm's APIs, and I have a helper defined in Site::Helpers:
$app->helper(
get_base_rest_url => sub {
my ( $self, $config ) = #_;
sswitch ( $config ) {
case 'photos': {
my $base_url = 'https://api.flickr.com/services/rest/';
my $user_id = '7281432#N05';
my $api_key = $self->app->config->{ 'api_token' }{ 'flickr' };
my $url =
"$base_url"
. "?user_id=$user_id"
. "&api_key=$api_key"
. "&per_page=" . $self->session->{ per_page }
. '&format=json'
. '&nojsoncallback=1';
return $url;
}
case 'music': {
my $base_url = 'https://ws.audioscrobbler.com/2.0/';
my $username = 'virtualwolf';
my $api_key = $self->app->config->{ 'api_token' }{ 'last_fm' };
my $per_page = $self->session->{ 'per_page' };
my $url = "$base_url?user=$username&limit=$per_page&api_key=$api_key&format=json";
return $url;
}
}
}
);
The problem I'm running into is that I don't know how to access that helper from the Site::Model::Photos module. The error is
Can't locate object method "get_base_rest_url" via package "Site::Model::Photos"
which is fair enough, but I can't work out how to actually get at that get_base_rest_url helper (or alternatively, how to access the api_token config).
The problem is that your module have not got app attribute/method which get access to your app.
So, when you create instance of Site::Model::Photos you need to pass app to it in param and make it weaken something like that:
package Site::Model::Photos
use Scalar::Util 'weaken';
sub new {
my $class = shift;
my $app = shift;
my $hash = {app => $app, ...};
weaken $hash->{app};
return bless $hash, $class;
}
sub your_method {
my $self = shift;
$self->{app}->get_base_rest_url(...);
}
1;
Or you may to use this module https://metacpan.org/release/Mojolicious-Plugin-Model which do it for you:
package Site::Model::Photos
use Mojo::Base 'MojoX::Model';
... code of your module ...
sub your_method {
my $self = shift;
$self->app->get_base_rest_url(...);
}
1;
And in your App.pm need to add this:
$app->plugin('Model', {namespaces => ['Site::Model']});
And use it that in controller:
$c->model('photos');
$c->app->model('photos');
I have a base class that is instantiated with a complex data structure with a three-digit number of entries, all of them constants. A few of those constants are class-specific and should be instantiated with different constants. I am having trouble achieving this. It boils down to this:
tstbase.pm:
package tstbase;
my $THISCLASSCONSTANT = "baseconstant.2";
my %complexdatastructure = (
"attribute.1" => "baseconstant.1",
"attribute.2" => $THISCLASSCONSTANT,
);
sub new {
my $class = shift;
my $self = { };
bless ($self, $class);
$self->_init( $THISCLASSCONSTANT );
return $self;
};
sub _init {
my $self = shift;
$THISCLASSCONSTANT = shift;
foreach (keys %complexdatastructure) {
$self->{$_} = $complexdatastructure{$_};
};
};
tstsubclass.pm:
package tstsubclass;
use parent "tstbase";
my $THISCLASSCONSTANT = "subclassconstant.2";
sub _init {
my $self = shift;
$self->SUPER::_init( $THISCLASSCONSTANT );
};
tst.pl:
#!/usr/bin/perl
use tstbase;
use tstsubclass;
my $baseobj = tstbase->new;
print "Testbase ".$baseobj->{"attribute.1"}." ".$baseobj->{"attribute.2"}."\n";
my $subobj = tstsubclass->new;
print "Testsubclass ".$subobj->{"attribute.1"}." ".$subobj->{"attribute.2"}."\n";
Right now the output is
Testbase baseconstant.1 baseconstant.2
Testsubclass baseconstant.1 baseconstant.2
whereas I want it to be
Testbase baseconstant.1 baseconstant.2
Testsubclass baseconstant.1 subclassconstant.2
Is that possible? I am happy to use
sub THISCLASSCONSTANT = { "subclassconstant.2" }
if it helps. tstsubclass shall not have any baseconstant values.
Right now I instantiate the class with magic strings and do a search & replace. It works, but seems less elegant and performant.
Any help is greatly appreciated. I have asked this question before ( Perl: Using common constructor for base and subclass ) but have over-simplified the example, hence the response could only hint at a possible solution.
Thanks,
Marcus
The simplest way would be to work with references in your %complexdatastructure.
But note that when doing this, $THISCLASSCONSTANT will be changed after the first call to tstsubclass->new.
package tstbase;
my $THISCLASSCONSTANT = "baseconstant.2";
my %complexdatastructure = (
"attribute.1" => \ "baseconstant.1",
"attribute.2" => \ $THISCLASSCONSTANT,
);
sub new {
my $class = shift;
my $self = { };
bless ($self, $class);
$self->_init( $THISCLASSCONSTANT );
return $self;
};
sub _init {
my $self = shift;
$THISCLASSCONSTANT = shift;
foreach (keys %complexdatastructure) {
$self->{$_} = ${$complexdatastructure{$_}};
};
};
Now your output is the desired one, but if you alter the order of the new calls like this:
my $subobj = tstsubclass->new;
print "Testsubclass ".$subobj->{"attribute.1"}." ".$subobj->{"attribute.2"}."\n";
my $baseobj = tstbase->new;
print "Testbase ".$baseobj->{"attribute.1"}." ".$baseobj->{"attribute.2"}."\n";
You'll get:
Testsubclass baseconstant.1 subclassconstant.2
Testbase baseconstant.1 subclassconstant.2
What you could do now is to write your "own" little local (i don't know why the normal local isn't working even with altering the declarations of $THISCLASSCONSTANT to our)
change your tstbase::_init into:
sub _init {
my $self = shift;
my $oldconstant = $THISCLASSCONSTANT;
$THISCLASSCONSTANT = shift;
foreach (keys %complexdatastructure) {
$self->{$_} = ${$complexdatastructure{$_}};
};
$THISCLASSCONSTANT = $oldconstant;
};
Now i think you have what you want.
I am reading the section of Mojolicious::Guides::Growing where it tells you how to grow a Mojolicious::Lite into a "well organized" cpan-uploadable application. First, it tells you to split the M::L app into a launch script and an application class.
package MyApp;
use Mojo::Base 'Mojolicious';
use MyUsers;
sub startup {
my $self = shift;
# ...auth stuff omitted...
my $r = $self->routes;
$r->any('/' => sub {
my $self = shift;
my $user = $self->param('user') || '';
my $pass = $self->param('pass') || '';
return $self->render unless $self->users->check($user, $pass);
$self->session(user => $user);
$self->flash(message => 'Thanks for logging in.');
$self->redirect_to('protected');
} => 'index');
$r->get('/protected' => sub {
my $self = shift;
return $self->redirect_to('index') unless $self->session('user');
});
$r->get('/logout' => sub {
my $self = shift;
$self->session(expires => 1);
$self->redirect_to('index');
});
}
1;
This makes sense to me. But then it goes on to say that this application class can further be refactored into a controller class with the actions, and the application class itself can be reduced to the routing information:
package MyApp::Login;
use Mojo::Base 'Mojolicious::Controller';
sub index {
my $self = shift;
my $user = $self->param('user') || '';
my $pass = $self->param('pass') || '';
return $self->render unless $self->users->check($user, $pass);
$self->session(user => $user);
$self->flash(message => 'Thanks for logging in.');
$self->redirect_to('protected');
}
sub protected {
my $self = shift;
return $self->redirect_to('index') unless $self->session('user');
}
sub logout {
my $self = shift;
$self->session(expires => 1);
$self->redirect_to('index');
}
1;
package MyApp;
use Mojo::Base 'Mojolicious';
use MyUsers;
sub startup {
my $self = shift;
# ...auth stuff omitted...
my $r = $self->routes;
$r->any('/')->to('login#index')->name('index');
$r->get('/protected')->to('login#protected')->name('protected');
$r->get('/logout')->to('login#logout')->name('logout');
}
1;
I don't see why this is superior to the "hybrid" version where routes and actions are intermingled, because now in order to redirect between the actions with redirect_to() in the controller, you need to look at the routing infomration in a different file, and if you want to change a url, you have to do it in two different files instead of one. This:
$r->get('/protected' => sub {
my $self = shift;
return $self->redirect_to('index') unless $self->session('user');
});
turns into:
sub protected {
my $self = shift;
return $self->redirect_to('index') unless $self->session('user');
}
$r->get('/protected')->to('login#protected')->name('protected');
Which has the word "protected" 4 times in two different files (although I'm not sure what the name("protected") does yet).
I'm a complete novice when it comes to web development, by the way.
It's not superior; rather, it's different.
As soon as you move beyond one developer, having your app in one file is no longer a benefit; you'll end up stepping on each others toes. Even if you're the only dev, it's never easy to keep track of locations in files of 1000+ lines. In addition, being able to look at one file and determine all your routes at a glance is quite useful when you have more than just a few routes, not to mention 100+.
Also, you don't have to change a redirect url in a controller action when the route changes. Mojolicious will do the work for you if you're making use of named routes.