Questions about registering and calling plugins

[belfasthenry]

Within a Mojolicious (not lite) application I have a plugin class Mojolicious::Plugin::PhotoArchive which I want to use from a controller Dirlist.pm, invoked by an application Pas.pm; it builds web pages displaying the photographs from a given directory.

I have two questions about how to write it and how to call it from the controller.

Firstly how the plugin is added. Careful examination of the Mojoilicious code tells me that the "plugin" method calls both the "new" and "register" methods from my plugin class, but that nothing is done to make the plugin available to the caller unless I do it. Is this correct? Using some other plugins as examples I have coded my "register" method thus:

sub register{
  my ( $self, $app, $parms ) = @_;
  # ... other stuff
  $app->helper( 'PhotoArchive' => $self );
  return $self;
}

Secondly how to call the plugin. Careful inspection using the Perl debugger shows that my plugin is available to the controller:

x $self->app->renderer->helpers
0  HASH(0x55bf4a780d40)
   'PhotoArchive' => Mojolicious::Plugin::PhotoArchive=HASH(0x55bf4a8ab8f8)
      ... etc

but if I call it thus
my $json = $self->app->renderer->helpers->{PhotoArchive}->get_dir('Sam');
I see from debugging my plugin code that there's no backwards reference to any part of the application (specifically i want the "public" directory). If that's how it works then I might as well recode my "PhotoArchive" class as stand-alone, then "use" it and call its "new" method, passing whatever I want.

I'm sure that's not how it works, and that I'm down a rabbit hole of misunderstanding. Can someone put me right on these two points?

[jberger]

While your first point is correct (most plugins don't care about their instances anyway, but you can do as you say) you've missed the point of helpers entirely in the second.

You've found where the coderefs are stored however they're used by calling them as methods on the controller or application (via a generic controller). When done that way they have access to the application.

I'm interested in how you came to be this misguided as clearly you have the effort to walk the debugger more deeply into mojo than I've ever taken it. Have you read the tutorial https://docs.mojolicious.org/Mojolicious/Guides/Tutorial#Helpers ? We recommend reading it and all the guides in the order listed here https://docs.mojolicious.org/#TUTORIAL

[belfasthenry]

Thank you for the prompt and knowledgable reply. I've been mulling it over ...

Yes, I had read the tutorials, with attention; but on your prompting I've read them again and I think I understand how I've got confused. In the "Growing" tutorial it shows a helper being defined to use a separate module, thus

helper users => sub { state $users = MyApp::Model::Users->new };
...
$c->users->check($user, $pass);

The "check" method is given $user and $pass and does its thing.

But nothing in the application (config data, the location of the "public" directory, HTTP parms etc) is accessible to the helper module (MyApp::Model::Users in the tutorial application), is it? That's what I was asking. I think I'm now right in saying that to allow my "PhotoArchive" module access to the public directory I'll need to pass it in as a parameter. I can do that, of course: modules out in the non-Mojo world are like that anyway. But in that case, of what value is defining a plug-in?

In other words, I don't see the difference between

helper users => sub { state $users = MyApp::Model::Users->new };
...
dostuff if $c->users->check($user, $pass);

and

my $checker = MyApp::Model::Users->new;
...
dostuff if $checker($user, $pass).

[kraih]

One caches the MyApp::Model::Users instance and makes it available everywhere in the application, and the other requires re-instantiation every time you use it.