Database driven menu "shared" in all pages that require it

There are obviouly a lot of ways to do it, the first is creating a class Menu with static funciton for example render and use it with {{ Menu::render() }}, or you could create a partial and use it after you have passed the values from the controller to the view.

There may also be some packages to accomplish what you need, try to google.

I'd go something like ...

• Create a master template to define the basic, consistent look and feel of your app.
• Create a view for your menu, which is a partial that you insert into your master using @include in the master template (or some other view).
• Create a menu model of some kind, so that you can refer to your database table that contains your menu data.
• Create a controller for your menu so that you can get your data stuff from your data model to your menu view (the view is the partial, above)

If the terms view, @include, model and controller are foreign to you in this context, watch some more Laracasts - they are covered over and over an over.

You could use view composers (http://laravel.com/docs/responses#view-composers). If you create a blade template for the navigation, and then add a view composer for that blade file. Then no matter where you include the blade template, the data required will be passed to the template file.

Thanks guys, lot of ideas here! :-) I was wondering what's the best approach among these, in terms of ease and performance... is there a laracast about these techniques?

on one project we had 3 database tables - modules - sub_modules

and user_modules_access

• modules = category of navigation item
• sub_modules = sub-category of dropdown
• user_modules_access = control what menu items should load for the user depending on his access

We have a Modules.php Model which basically build the array of links and the View looped through the array and build the menu.

Ease and performance ... you may not be able to get both at the same time.

If you're new at it, then perhaps easiest is the most important. Arguably, the approach I outline might ... might be the easiest. It is certainly the approach that is most documented on this site.

But every other option here has an upside that validates it as a choice. Certainly, all of the other options I think are closer to what may be considered better practice.

Performance? Mate ... no matter what you choose it will be fast enough.

Pick one and get cracking :)

Use this: https://github.com/sdbruder/laravel-menu

The download.zip is recently updated for Laravel 5 and it works for me.

@FrancoM this thread was 10 months old!!!

@mstnorris It is 'ageless'. There is always some 'lost soul' (like me) looking for answers :)

Another way (5.4 - did not earlier versions) is:

• service provider,
• boot() method and
• View::share, where 'value' holds e.g. array/collection with data to be looped in menu.

Idea is, that you probably want to share menu data across system and View::share allows just that.

Then what you need is some view blade with html @include(ed) wherever you need your menu.

https://laravel.com/docs/5.4/views#passing-data-to-views

EDIT:

Powering dynamic menu data via Provider is not a good idea, if you need access to Authorized User object.

Say, you want to limit access to menu parts based on user role, or something similar.

In above case, Provider is not your friend, as it comes to party before anybody else. In other words, user is not authenticated yet, when your code is being run via Provider. So, I guess View Composer in that case is not good as well.

I am not sure, maybe View Creators - see bottom of this page. https://laravel.com/docs/5.4/views#view-composers I haven't tried them.

But to the point.

After some trial'n'error I decided to go for Middleware, run by 'web' middleware group. These guys seem to show up after authentication, so user object is available already.

Just, if you use repository, remember to inject it via constructor and then using protected method pass it to method handle. Trying to let it resolve for you via Service Container (directly as 3rd argument in method handle) will not work.

I used View::share, but I think you can also use composers, as they are not attached by the hip to Provider, they just use it as launching point.

This is not mine, someone else coined this phrase:

"If it stupid, but it works, it ain't stupid."

Well, we'll see about that ;)