Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

weeniebeenie's avatar

What is the convention on displaying related data on a different page/view?

Having watched the beginner Laravel series here, read the docs and watched a few other videos I've got most of the basics down (I think!) but something I've not seen covered anywhere is when you want to display related data on a seperate page to the main data. I know how to get related data defining the model relations, but any example I've seen just uses that relation on the same primary page/view.

Take a generic example, if you had events of some sort and a relation of people that were at each event, you'd have a M2M relationship set up on the models and an event_person pivot table.

//Event.php Model

    public function people()
    {
        return $this->belongsToMany(Person::class);
    }

//Person.php Model

    public function events()
    {
        return $this->belongsToMany(Event::class);
    }

Then you'd set up the route and controller (Or do it as a resource controller, whatever)

Route::get('/events/{event}', [EventController::class, 'show']);

Then the show function in the controller would be something like:

    public function show(Event $event)
    {
        return view('events.show', [
            'event' => $event->load('people'),
        ]);
    }

Then I could display the people on that view, fine. But what if instead I'd like to display the people at a dedicated /events/123/people sub-page, based on a different view? And in a real world, there might be several of these sub pages, potentially all with a completely different layout/view needed.

I can think of several ways to do this but it seems like a pretty common enough scenario that there is a convention I should be following?

  • Have the extra route(s) use the same Event@Show method and use if statements on the controller to return a different view and data depending on the route request?
  • Creating extra methods in the EventController, i.e eventPeople()?
  • Creating a PersonEventController and so on?

Or something else I'm not thinking of? I'm leaning towards the first option but would appreciate some guidance to make sure I'm following the conventions, thanks!

0 likes
5 replies
jj15's avatar
jj15
Best Answer
Level 10

All of the ways you listed are viable solutions depending on how large your application is and how you prefer to structure it.

From what I've seen and in my own opinion:

  • The first method is simple but can become convoluted quite quickly as the controller/method needs to handle more responsibilities.

  • The second is a much cleaner solution but some developers prefer to keep their controllers focused on only handling the CRUD (Create, Read, Update, and Delete) actions for each type of resource, even if it's not a separate model.

  • The third is probably the best and what I prefer to do in most cases. Laravel also allows you to create an "invokable" or single-action controller. So you might have an EventController and ShowEventAttendeesController depending on your requirements. Here is an article on this approach.

Again, it depends on your specific application and personal preference.

2 likes
Tray2's avatar

There isn't really any difference between what you are trying to do and what you previously done.

The controller fetches the data, passes it to the view, and the view renders it. The only thing you need to consider is the name of the route and the controller.

Take artists, records and tracks as an example.

The Artist name and the records title will most likely be shown on the records.index page.

/records

You ca then click on the artist, and see all the records by that artist, and that view would be artists.show.

/artists/{artist}

If you instead click on the record, you will fetch the information about the tracks, and possibly all the other records that artist has created. The view would be records.show.

What you show in your views are up to you, you don't need to make a view for each table, you can combine them when it makes sense to do so.

1 like
Snapey's avatar

Stop thinking that views and controllers are for a crud of a specific resource.

They are for whatever you want.

The controller orchestrates collecting the required models (from as many models or relationships as required, and the view is built to solve the task as required.

1 like
weeniebeenie's avatar

Thanks all, your replies are all reassuring! I'm just a hobby coder planning to completely rewrite from scratch in Laravel a pretty big spaghetti vanilla PHP site I first made about 15 years ago so I guess I'm extra cautious about getting it all right off the bat this time.

jj15's avatar

@weeniebeenie Thank you for awarding me as best answer. I totally understand where you're coming from and wish you the best of luck!

Please or to participate in this conversation.