"Many people" != "Mojolicious people". This is a very generic problem,
where a higher level object pass itself to a lower level object. What I
mean is that you build stuff from small components built on top of each
other, and then you have this high level object on top which "orchestrate"
the objects, passing on just enough information to make each of them work.
I will try to come up with a new example. Which of these two lines of code
makes most sense to you?
$user = $c->model->users->find({id => $c->param("user_id")});
$user = $c->model->users->find($c);
Btw... I'm drifting. Your original question is very specific and not
explaining why you want to pass $app to the model. Can you try to explain
why you need to pass on $app to the model? Do you have an example
usecase/piece of code where that makes most sense?
On Monday, April 20, 2015 at 11:10:20 AM UTC+2, Eugene Toropov wrote:
>
> Right, well, I hope Sebastian will have a moment to reply at some point if
> it comes up so often and so many people were "in the same state of mind" :)
> Or he did already? If so - would be great if someone could provide a link.
> Thank you.
>
> Cheers
> Eugene
>
> On Apr 20, 2015, at 11:49 AM, Jan Henning Thorsen <[email protected]>
> wrote:
>
> It's so funny how this questions comes up over and over again. I even have
> to battle it myself from time to time, even when I know how stupid (Sorry
> for using "stupid", but I think I'm allowed as it reflects back on myself),
> limiting, hard to get around later, ... it would be to pass some $app-like
> object around to lower level models.
>
> Also, I probably know how your mind is set on your statement, and how you
> probably just want to get confirmation instead of the answer I'm giving
> you. Yes... Me and many before you have been in the same state of mind.
>
> So... I was hoping I could help you with my Mojo::Pg->new() example above,
> but it seems like I have failed.
>
> I wish you the best of luck finding the right solution.
>
> I also apologize if I'm stepping on yours or anyone else's toes. That is
> not my intention.
>
>
> On Monday, April 20, 2015 at 10:31:45 AM UTC+2, Eugene Toropov wrote:
>>
>> Hi Jan,
>>
>> Having to pass "db => shift->model->db” in every model helper doesn’t
>> seem like invisible way ;) It would be really invisible if you had “use DB”
>> inside a model package and then “my $db = $DB::dbh” :) but then you’d have
>> to somehow pass app->config to DB. Also if you kept something in
>> app->config that model needs - would you pass it as another parameter to
>> every model you had? What if then you had app->cache (redis/memcached) ?
>> Another parameter to pass to every model again? I feel it doesn’t seem good
>> but can’t find any other way in Mojo to do it so thought someone had found
>> the solution...
>>
>> Cheers
>> Eugene
>>
>> On Apr 20, 2015, at 11:18 AM, Jan Henning Thorsen <[email protected]>
>> wrote:
>>
>> I pass on $db to every instance of a model in MCT:
>> https://github.com/mojoconf/MCT/blob/master/lib/MCT.pm#L33
>>
>> Just make a helper where the passing of $db (or any other common
>> argument) is "invisible".
>>
>> The nice thing is that the model will need to know less. It will then be
>> easier to use for "other things" outside of your Mojo app. To flip the
>> question around. Which version ofof the code below makes most sense?
>>
>> my $app = Mojolicious->new;
>> $db = Mojo::Pg->new(app => $app);
>> $db = Mojo::Pg->new(app => $app->config->{db}{dsn});
>>
>> (I hope the version where $app is passed to new() looks weird...)
>>
>>
>> On Monday, April 20, 2015 at 9:17:27 AM UTC+2, Eugene Toropov wrote:
>>>
>>> Hi Jan,
>>>
>>> Thanks for your reply. Don’t you think that passing app->db to every
>>> model is not a good idea neither because model must know itself where data
>>> are and how to fetch it and pass to controller? Also it’s simply
>>> inconvenient to always have one (or even 2 - app->db and app->redis for
>>> example) arguments passed to every model, no?
>>>
>>> Cheers
>>> Eugene
>>>
>>> On 20 Apr 2015, at 10:07, Jan Henning Thorsen <[email protected]>
>>> wrote:
>>>
>>> You don't. Passing $app or $c to a model is not a good idea. Reason for
>>> this is that it makes it hard to reuse the models elsewhere. What you can
>>> do, is passing data from $app when you construct your models, but I would
>>> strongly advice against passing $app.
>>>
>>>
>>> On Friday, April 17, 2015 at 4:38:06 PM UTC+2, Eugene Toropov wrote:
>>>>
>>>> Greetings,
>>>>
>>>> In the following example how will you make MyApp::Model::Users have
>>>> access to app object (which is basically $self) that is necessary to use
>>>> app->db and app->config?
>>>>
>>>>
>>>> http://mojolicio.us/perldoc/Mojolicious/Guides/Growing#WELL-STRUCTURED-APPLICATION
>>>>
>>>> package MyApp;use Mojo::Base 'Mojolicious';
>>>> use MyApp::Model::Users;
>>>> sub startup {
>>>> my $self = shift;
>>>>
>>>> $self->secrets(['Mojolicious rocks']);
>>>> $self->helper(users => sub { state $users = MyApp::Model::Users->new });
>>>>
>>>> my $r = $self->routes;
>>>>
>>>> $r->any('/' => sub {
>>>> my $c = shift;
>>>>
>>>> my $user = $c->param('user') || '';
>>>> my $pass = $c->param('pass') || '';
>>>> return $c->render unless $c->users->check($user, $pass);
>>>>
>>>> $c->session(user => $user);
>>>> $c->flash(message => 'Thanks for logging in.');
>>>> $c->redirect_to('protected');
>>>> } => 'index');
>>>>
>>>> my $logged_in = $r->under(sub {
>>>> my $c = shift;
>>>> return 1 if $c->session('user');
>>>> $c->redirect_to('index');
>>>> return undef;
>>>> });
>>>> $logged_in->get('/protected');
>>>>
>>>> $r->get('/logout' => sub {
>>>> my $c = shift;
>>>> $c->session(expires => 1);
>>>> $c->redirect_to('index');
>>>> });}
>>>> 1;
>>>>
>>>> Cheers
>>>> Eugene
>>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Mojolicious" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> To post to this group, send email to [email protected].
>>> Visit this group at http://groups.google.com/group/mojolicious.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Mojolicious" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To post to this group, send email to [email protected].
>> Visit this group at http://groups.google.com/group/mojolicious.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
--
You received this message because you are subscribed to the Google Groups
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
