Hi, I am going to develop webshop for several companies, and I have to develop an admin interface as well.
The different companies need different modules for the webshop's admin interface, so I need to find the way to use modules for admin interface. Until now the admin interface was a module, but I cannot create modules under admin module.
So my plan is to create a different FuelPHP instance for the admin interface, but I am afraid that I can't upgrade Fuel easily.
My other idea is to have modules in two directories (modules/admin/, modules/public/) and have the modules autoloaded in the admin interface by name of the directories.
Third idea is to copy the specific files in the main application directory and have an install script in each class. This is not a very good idea, I think.
Fourth idea is to have an own package manager, and install modules for example from zip archive. With this solution I could not just copy the files to their place.
I would do the first way, but I am afraid I cannot update fuel.
What is your opinion. How would you/do you solve this problem?
We use an application framework where there is an admin module that provides the admin interface.
Every module installed registers it's admin component, which then integrates into the admin interface and it's menu system. Access to the different admin features and menu items is controlled by standard Auth roles and rights, which are defined in the form "module.rightname".
This system allows you to design new modules, which will appear automatically in the admin interface if the user has the rights to them.
This system is even used in SaaS type applications, where the Theme class provides a different look-and-feel for every client. The theme to load is selected based on hostname, as every client has it's own subdomain, which all point to the same virtualhost.
If I understand well, every module registers its own components under the Admin module namespace (I guess), and declares the minimum access required to view this module.
I was thinking about this solution.
About the menu: I am writing a Database based menu, but this way it is not the best solution. My idea is to create a function in the menu class to be able to create my own menu items in the code. Is it a good idea? Or create menu from code for the admin menu, for example in a config file. How do you do this.
Also it is time to say a big THANK YOU, not just for your work, but also for making a good support and help to understand, what Fuel is. So: THANK YOU
You're welcome. I am a firm believer of good support, it makes or breaks a product. Thanks for the kudos.
In our case, every module has a class called Module (in the modules namespace). It has methods that provide the admin module the menu items, the roles defined by the module, the rights that can be assigned to roles (not only the module roles), and the admin widgets this module exports.
The admin module controller polls all these classes, and caches the result so it doesn't have to scan and pull all modules every time. It then uses that to create an array structure that contains the entire menu, including details like submenu's, menu icons, and rights. This array is cached too.
Upon display, this array is read, any items the user doesn't have access to are filtered, and the rest is used to display the menu.
We use the same system for the frontend btw, where it exports dashboard widgets (every user is presented his personal dashboard after login to the application).
Ok, I understand the way you do. As I said in my earlier comment, I use a menu package. Now I extended it to be able to create menu from array.
So what if the admin controller calls the module's some kind of init function, and this function places for example the menu items in the cached array.
This way admin controller has nothing to do, just call the proper function, when it detects that a module is not yet cached, and the module does the rest. Also this way the module has to follow some rules. Maybe this is the way you do, and I did not understand it. :)
We have the logic on the calling side, the module only delivers the data. But you can put the logic on the module side as well, it doesn't really matter.