Class 'Anomaly\Streams\Platform\Model\Redirects\RedirectsDomainsEntryModel' not found
Created 6 years ago by pooriaAfter I updated redirect-module
I am getting this error. What is the problem?
For "Class 'Anomaly\Streams\Platform\Model\Redirects\RedirectsDomainsEntryModel' not found" - you just forgot to run the new migrations?
@webformatik I fixed the problem. But now my question is in my second post. It's really difficult to understand Repository model for me.
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.
@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
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.
I am a little confused on how this bindings work. There is a binding in each module's service provider class like this:
What I get from this code is that every call to
NamespaceSlugEntryModel::class
will giveSlugModel::class
. But the strange thing for me here is thatSlugModel::class
extendsNamespaceSlugEntryModel::class
andNamespaceSlugEntryModel::class
does not exist as a file! So It's like thatSlugModel
is extending itself!!