Hi Guys
Ok, so I am just thinking about how to go about building menus in my application.
Here is how I think it should work but I would like you to give me ideas, suggestions and the best way to go about it.
So, My app is a basic CMS, each module of this CMS is it's own package so for example, at the moment I have the following packages:
Blog Portfolio User
These packages have been custom built by me. The CMS has two areas, front & backend. The User package contains roles that limits access using filters.
What I want is a easy, simple way to build a MenuBuilder package, that will allow me to create, assign, edit menus in a similar way to Wordpress, but the items available to build the menu depends on the packages available on that site. For example, if the site doesn't contain a blog, then don't show the blog navigation item in the Menu Builder.
One way I was thinking it could work is that I create a Core package that creates a available_navigation_items table, each time a package is installed it would add an item to this table, however, this is limiting me a little as I would like to one day make each package available to the public and I don't want them to have to create navigation_item tables or rely on the core package as well e.t.c
Or, could I use available routes or something?
So, what are your thoughts on how to handle something like this using best practices and ensuring that it is future proof and flexible?
Thanks in advance :)
Chris
No, not quite, doesn;t that package just add an active class?
I need lists of the navigation items available to maybe be stored in a database so that I can build navigations from them via the admin area. Think Wordpress and how that handles it's menus.
Well, I'm sure there're many approaches. Here's one that I can think of now.
Each modules provides a config that contains title. Your CMS loops through each modules and collect the titles. Of course, titles should be cached in a way. It really doesn't have to be a table. It can be a file as well.
moon0326 said:
Well, I'm sure there're many approaches. Here's one that I can think of now.
Each modules provides a config that contains title. Your CMS loops through each modules and collect the titles. Of course, titles should be cached in a way. It really doesn't have to be a table. It can be a file as well.
Great idea, I may look in to this one a little further, how would I go about looping through each module config and get the title?
You can simply loop through module directories and just get the config file (I know it's naive technique :) ) and cache those values. I'm sure there're many approaches, but that just popped up in my head.
If you plan to provide modules for a CMS, I assume you would provide an admin interface to disable/enable modules and a way to clear module configuration cache. Since the module configuration admin interface will not be user facing website, I would not worry about performance much.
Have each of your core modules fire an event that registers the module with the base application. You can then use the list of registered modules to determine what is installed or not.
You could even go further and register modules based on Auth logic, subdomain being used etc. Each module simply fires off an event in their boot/register method in the corresponding ServiceProvider and your MenuModule (or whatever you want to call it) listens for the responses to determine what other modules have been loaded.
Another option is a generic AppServiceProvider that contains an abstract class that your other service providers extend that could keep this logic in a single place so you don't have to repeat yourself.
abbajbryant said:
Have each of your core modules fire an event that registers the module with the base application. You can then use the list of registered modules to determine what is installed or not.
You could even go further and register modules based on Auth logic, subdomain being used etc. Each module simply fires off an event in their boot/register method in the corresponding ServiceProvider and your MenuModule (or whatever you want to call it) listens for the responses to determine what other modules have been loaded.
Another option is a generic AppServiceProvider that contains an abstract class that your other service providers extend that could keep this logic in a single place so you don't have to repeat yourself.
Perfect, this seems like a much better way of doing it! Thanks
Sign in to participate in this thread!
Laravel
Laravel News
Laracasts
Laravel Podcast