pooria - 2 weeks ago

After I updated redirect-module I am getting this error. What is the problem?

pooria - 2 weeks ago

I am a little confused on how this bindings work. There is a binding in each module's service provider class like this:

protected $bindings = [
    NamespaceSlugEntryModel::class => SlugModel::class,
];

What I get from this code is that every call to NamespaceSlugEntryModel::class will give SlugModel::class. But the strange thing for me here is that SlugModel::class extends NamespaceSlugEntryModel::class and NamespaceSlugEntryModel::class does not exist as a file! So It's like that SlugModel is extending itself!!

pooria - 2 weeks ago

Anyone?

webformatik - 2 weeks ago

For "Class 'Anomaly\Streams\Platform\Model\Redirects\RedirectsDomainsEntryModel' not found" - you just forgot to run the new migrations?

pooria - 2 weeks ago

@webformatik I fixed the problem. But now my question is in my second post. It's really difficult to understand Repository model for me.

ryanthompson - 2 weeks ago

Migrating the addon would/should have fixed this one.

In laravel and Pyro - the model is often the Entity. So for better separation of concerns for us within the application we use the repository interface to act on behalf of the database and the model to act on behalf of the entity. You don't have to - but by default it's setup that way.

Otherwise you would have database methods right next to potential entity methods and it would be less desirable from a design standpoint.

For example $payments->findAllByCard($card) and $payment->complete() should not both reside on the model by good design standards. So we use a repo for the DB / fetching and the model for the entity itself.

Hope this makes sense! Long story short it's a design/organization preference but you don't have to abide by it at all. People use MyModel::find($id) for example all the time and use queries that way.

pooria - 2 weeks ago

@ryanthompson Thanks Ryan. I read some articles about reps but I'm a little uncomfortable using them :)), BTW, now my problem is this (maybe my knowledge of PHP):

SlugModel::class extends NamespaceSlugEntryModel::class and NamespaceSlugEntryModel::class does not exist as a file! So It's like that SlugModel is extending itself!!

How is this working? o_O

ryanthompson - 2 weeks ago

This is part of the magic of how streams works internally. When you create a stream in a namespace - Pyro makes a model for you following the NamespaceSlugEntryModel::class format. And to make it easier to extend functionality there - it also makes a model in your addon that extends the required internal one. Which you can delete (the addon one) if you really want. As with some of the other classes. It builds it all for you and you can decide what you want.

When you install/migrate that addon the model will be generated. If it's already installed - you may need to run php artisan streams:compile which will go through all streams and compile their corresponding models.

Part of the model extending thing is so that the table builder in your addon can automatically detect the model / repo and models can detect criteria and presenters. Since they're right next to each other it's some crafty name manipulation to figure out that FooPresenter is / could be right next to FooModel so you don't have to connect them. They just pick up if they're there or fallback to default ones if not.