I like the gate for the "show" route because it's very clear what it's doing. Maybe you could achieve the same "self-documenting" result for the index page by writing that restriction as a query scope? That would also help if you need a collection like that in multiple places in your app, and you still keep the efficient DB querying.
I get the DRY principle, but sometimes as you sail in other videos, it can hide logic from the dev. I've seen a few people having headaches because they were new in the ecosystem and couldn't find some things. This was mostly their fault for relying too much on xDebug and not knowing that they put breakpoints after the logic was executed. On the other hand I feel like some things regarding permissions should stay at the middleware level.
I know it's not the topic, but it is BelongsToMany stuff: Are there cases when you would create the Pivot Model with extra stuff ? And if yes, is it possible to work with the pivot model on routing ?
there are a lot of moments you need to store extra data in your pivot tables, the easiest one is a star voting system where you have a user vote from 1-5 on an product in an online shop. You have the many to many relation with the primary key user_id+product_id, then you have the vote value, and maybe a createed_at and updated at. additionally you might want a comment column for a review/opinion on the product Another example is when you have a user subscribe option. You basically have the user subscribe to let's say a service and you have additional options that are toggled on/off that you might want to set in the many to many relation table. Now i get the SQL nerds will recommend you store it in a separate table, but depending on the project having an additional table ads more work than needed
@@LaravelDaily Let's say you have Users, Accounts, and Subaccounts, User BelongsTo Account and can BelongToMany Subaccounts, may be this is bad to have SubaccountUser Pivot Model and the need to handle Roles and Routing on it ?
This just threw me off balance i was preparing to use gate to create a nexted user roles. For instance i already i have a userType, this userType is used to separate admin, user and vendor in the users table, then another admin table incase I have columns specific to the admins i used userid to relate it to the users table. I just included a role column in the admin table so i can use it to set manager, staff, and intern. And decide what they can perform on the admin section views based on this roles. How do you sugges i go about this.
I never create users and admins as separate tables, as they are already "user types" for me, so the logic should be in "users" table, with then roles/types on top. So, in your situation, sorry, I don't have any advice, I've never done it this way.
The employer->id pertains to the relationship between the user and employer models, hence, it will return the employer id of the current authenticated user. Whereas, the employer()->id is just a syntax or logical error. Since you are calling a method of user model which does exist, but it will not return the employer id
I like the gate for the "show" route because it's very clear what it's doing. Maybe you could achieve the same "self-documenting" result for the index page by writing that restriction as a query scope? That would also help if you need a collection like that in multiple places in your app, and you still keep the efficient DB querying.
Its a trade-off between choosing DRY or KISS
Can you give an example of how that will work/be created
Great video!👏
I usually put that stuff in a separate class using local scope
I get the DRY principle, but sometimes as you sail in other videos, it can hide logic from the dev. I've seen a few people having headaches because they were new in the ecosystem and couldn't find some things. This was mostly their fault for relying too much on xDebug and not knowing that they put breakpoints after the logic was executed.
On the other hand I feel like some things regarding permissions should stay at the middleware level.
I know it's not the topic, but it is BelongsToMany stuff:
Are there cases when you would create the Pivot Model with extra stuff ? And if yes, is it possible to work with the pivot model on routing ?
there are a lot of moments you need to store extra data in your pivot tables, the easiest one is a star voting system
where you have a user vote from 1-5 on an product in an online shop. You have the many to many relation with the primary key user_id+product_id, then you have the vote value, and maybe a createed_at and updated at. additionally you might want a comment column for a review/opinion on the product
Another example is when you have a user subscribe option. You basically have the user subscribe to let's say a service and you have additional options that are toggled on/off that you might want to set in the many to many relation table. Now i get the SQL nerds will recommend you store it in a separate table, but depending on the project having an additional table ads more work than needed
Yes you may have a separate Pivot model, usually if you need to save extra data.
But no, I haven't seen it used in Routing specifically directly.
@@LaravelDaily Let's say you have Users, Accounts, and Subaccounts, User BelongsTo Account and can BelongToMany Subaccounts, may be this is bad to have SubaccountUser Pivot Model and the need to handle Roles and Routing on it ?
@@julienSibilleif subaccounts are authenticatable why not use same User model with a team approach
This just threw me off balance i was preparing to use gate to create a nexted user roles. For instance i already i have a userType, this userType is used to separate admin, user and vendor in the users table, then another admin table incase I have columns specific to the admins i used userid to relate it to the users table. I just included a role column in the admin table so i can use it to set manager, staff, and intern. And decide what they can perform on the admin section views based on this roles. How do you sugges i go about this.
I never create users and admins as separate tables, as they are already "user types" for me, so the logic should be in "users" table, with then roles/types on top. So, in your situation, sorry, I don't have any advice, I've never done it this way.
What is the difference between auth()->user()->employer->id and auth()->user()->employer()->id?
If I'm not mistaken, the employer()->id wouldn't return the ID for you.
The employer->id pertains to the relationship between the user and employer models, hence, it will return the employer id of the current authenticated user.
Whereas, the employer()->id is just a syntax or logical error. Since you are calling a method of user model which does exist, but it will not return the employer id