1

I'm pretty new to Laravel, so I'm struggling with the logic for what is essentially a CMS with multiple content types.

Say I have 3 content types; Food, Books and Cars. Every item in all content types has a name, URL and a couple of other fields.

I can create, update and delete any of these resources with most likely the same code replicated 3 times. The only difference would be with a create or update as the field names would differ between them.

Should I just duplicate these fields/functions for each controller, or create some common ground in one place?

The crossover of fields/functions initially will not be huge, however, it seems inefficient let's say if I had 10 content types and I want to add one field to all of them I have to update code in a large number of places.

If I had a central "Node" that contained the id's and common fields for ALL items in every content type, then have this linked to individual tables for the custom fields, I'm in a much better position when I want to add, update or delete common fields.

I've currently got 3 controllers and have only worked on one so far so I have an index(), show() and edit() function in the controller.

As a test, I created a Node model with php artisan make:model Node -mcr and simply extended the existing Controllers so they were extending NodeController. Which just threw up an error like this;

Declaration of App\Http\Controllers\FoodController::show(App\Food$food) should be compatible with App\Http\Controllers\NodeController::show(App\Node $node)

This is likely not the way to go about it anyway, but I simply do not know the recommended practice for this.

Novocaine
  • 4,692
  • 4
  • 44
  • 66

1 Answers1

0

Most appropriate and standard best practice for your problem is,

have a single database table, let's say table name as node, which will contain all the common fields, and have another table as categories and relate it with node table (1-m) to categorize type of node such as car,book,food etc., and make one more table, let's say node_meta which will store all additional attributes depending on the type of node, (you may have a look on the wordpress CMS database ER Diagram which has similar db design.)

Polymorphic relation is not a good idea for this as stated by another user above, it has some limitation when it comes to querying underlying data, for example you cannot apply whereHas query and still there is no official solution to this problem.

Mohamed Akram
  • 2,244
  • 15
  • 23
  • I donot know the reason why you have down voted my answer, but its apparent your questions is not something related to Laravel, its about appropriate Database design in the first place, and then you can have one controller to avoid duplicate codes, anyway you shown me your stupidity down voting my answer.. – Mohamed Akram Jul 17 '18 at 06:54
  • 1
    Please note, I'm **not** the down voter. I see no need to down vote it personally. I understand my problem is not just a Laravel problem, as you say it is database design too. It is certainly not one or the other as I know I could come up with a workable solution in plain PHP, but obviously I want this solution to work well with Laravel and Eloquent so I'm manually getting/setting data unnecessarily. – Novocaine Jul 17 '18 at 08:08
  • I am really sorry to blame you then, I couldn't find who down vote and ran without giving a comment for the reason for down voting, stack overflow should be very strict on this matter, since we spend our time and writing appropriate answer, and people down vote it and run without valid reason and just to increase their reputation, this is not really fair and make me feel to close my so account.. – Mohamed Akram Jul 17 '18 at 08:13
  • While there is not an official solution to using whereHas with polymorphic models, solutions do exist: https://github.com/laravel/framework/issues/5429#issuecomment-268178279 – Brian Lee Jul 17 '18 at 21:26