Consider core automatic loading for Model and Task namespaces

[dmanto]

As discussed in Mojo IRC, personally I feel like application class (i.e. file lib/MyApp.pm) gets a little verbose when you have several Models and or several Tasks in your project.

So TL;DR, is it worth to add a feature for treating Model and Task namespaces as Controller namespaces (in the sense that they not need to be specifically loaded by the application)?

As an example if I have a project with 3 models and 2 tasks, the lib directory will probably look like:

|- lib
|  |- MyApp.pm
|  +- MyApp
|     +- Controller 
|        |- Foo.pm
|        |- Bar.pm
|        +- Baz.pm
|     +- Model
|        |- Foo.pm
|        |- Bar.pm
|        +- Baz.pm
|     +- Task
|        |- Qux.pm
|        |- Quux.pm

And inside MyApp.pm, I will probably have something like this: (this is following what I understand are best practices following Mojolicious documentation and examples)

use MyApp::Model::Foo;
use MyApp::Model::Bar;
use MyApp::Model::Baz;

# .... then somewhere inside statup method ...

$self->helper(
    foo => sub {
      state $st = MyApp::Model::Foo->new(app => shift->app);
    }
  );
$self->helper(
    bar => sub {
      state $st = MyApp::Model::Bar->new(app => shift->app);
    }
  );
$self->helper(
    baz => sub {
      state $st = MyApp::Model::Baz->new(app => shift->app);
    }
  );

# ... and finaly load Tasks, that are conveniently written as Plugins:

$self->plugin('MyApp::Task::Qux');
$self->plugin('MyApp::Task::Quux');

(The Model:: modules may actually need or not to have an app attribute (has 'app'), this is just an example)

If you think that this is too verbose (like I do), a possible refactoring of it is:

1. rewrite all your Model:: modules as plugins (i.e., using 'Mojolicious::Plugin' as the Mojo::Base class and adding the "register" method to install the corresponding helper).
2. add an universal loader for all MyApp::Model and MyApp::Task namespaces. Something like this will do it:

use Mojo::Loader 'find_modules';

# and then inside your startup method:

$self->plugin($_) for map { find_modules __PACKAGE__ . "::$_" } qw/Model Task/;

Instead of the "use" and helper loads lines for every Model:: module and the dedicated plugin line for tasks.

But the real question is that if it is worth to add a feature to preload code for these two namespaces that could be included in core. That would mean that you have to refactor (or start writing) your Models as Plugins, and the "use" statements and the helper loading code will not be needed.

[Grinnz]

I don't see how it could be done sensibly, because Mojolicious does not prescribe any relevance to the naming (or even existence) of such classes - you don't direct the router to them, they have no built in relationship to helpers, etc.

On another note, you can add such a namespace to the new https://metacpan.org/pod/Mojolicious#preload_namespaces attribute, but this only preloads it so that its memory is shared by prefork workers, you still need to require modules when using them.

[dmanto]

mmm I'm no sure I understand, but I think the naming of the helpers would be just a matter of best practices, probably a snake case of the Model's name camel case

[Grinnz]

It's not the naming that's the problem but that there is no mechanism to declare that you want to use such a class, which would indicate to Mojolicious to first ensure it is loaded, and then do something with it. Like the plugin method.

[dmanto]

ah ok, yes, something like point 2) mentioned above should be taken care by the feature

[kraih]

As far as i can see nothing prevents you from prototyping a solution as a plugin.

[dmanto]

hmmm, not being able to find a sensible name for it counts?

[jberger]

I wrote a module that might be interesting for you. It was me searching for a solution to a similar problem you were having. I'm not convinced that I nailed it but it does the job in the few places I've actually wanted it.

https://metacpan.org/pod/Mojo::TypeModel

Note that the examples refer to an application called CarPark which is only on my github

[elcamlost]

There is a https://metacpan.org/pod/Mojolicious::Plugin::Model that might suit your needs

[dmanto]

Thanks, the end result looks very similar, and you don't need to load models one by one.

I actually like more the "Mojo" way of helpers named after the models, like using $c->users->... instead of $c->model('users')->..., but this also looks interesting.

Do you know why you need to base on that MojoX::Model class?. In my current projects I started to use the approach mentioned in points 1) and 2) above, so extending Mojolicious::Plugin would be more than enough (I mean it shouldn't be necessary to go outside Mojo framework for this).

[elcamlost]

You need it to get properly constructed weaked app singleton inside your model.

Mojolicious::Plugin

1. has no app attribute;
2. you need to manually register plugin on startup calling $app->plugin to inject app link there
3. plugin has a bit different semantic: usually it is external code that somehow extends common logic and doesn't contain app specific logic. For example, you use a plugin to connect to database, but use different models to properly extract or inject data from different database tables.

[kraih]

A well designed model does not need the app instance, and can even be used independently, outside of a web application context.

[kraih]

At least for Minion better task class and class loading features are very possible. I just don't know yet how to do it.