Create a db-driven menu and hook system

[uaktags]

Menus are currently hard-coded in the templates, which leaves much of the work to the end user to update manually when modules are created. DB layout could be:

menu_gp ID Name (For administrative viewing) Location_ID (Used in Hook system, replaces {MENU_LOCAL#} with this group) menu ID MGP_ID (Group it belongs to) Parent_ID (Null default...otherwise it'd list parent in dropdown hierachy) Caption URL Themes can be built now to incorporate menu structures dynamically. Instead of modifying it by hand, theme developers will be able to create space for their menus. Location_1 is TopMenu, Location_2 is left side, Location_3 right, etc etc.

[ferdis]

I quite like the the way Wordpress does this particular thing, given, there are a few things I would change.

I suggest a multi-hierarchal approach, where each item has a parent. The only constraint that WP has that I wouldn't want to implement is that this whole process is way to coupled to be any good. I'll vote for a anything-goes approach.

On line with the suggestion you posted, I'll add the following: Drop the menu groups table, it holds no real merit when you take into account that it's just a parent itself.

`menu`
id (int) AUTO_INCREMENT, # unique identifier
parent_id (int) default NULL,  # if null, it is a group
title (char) default '', 
uri (char) default '', # should parse url to a module firstly, or else outbound

Index on: id, parent_id

[uaktags]

The group idea held the connection between the menu_parent_ids and the template's display code. Its how you will know which menus to load. Right now you'd have for say a menu of -Home (mid#1) -City (mid#2) --Bank (mid3 pid#2) --Store (mid4 pid#2) --Hospital (mid#5 pid#2) -Account (mid#6)

Now you have 3 groups but noway to tell the template to load those three groups, where as having a group setting tells them that all these belong to grp#1 also named friendly-named "User Menu" so that we can tell the template that If (LoggedIN) {Load_MenuGroup#1}Else{Load_MenuGroup#2}

I have to look at the way that WP does it, but this is my understanding of how WP looks like it does it, from an end-users look at it

The only way i see your method working is if -UserMenu (mid#1) --Home(mid2 pid1) --City(mid3 pid1) ---Bank(mid4 pid3) ---Store(mid5 pid3) ---Hospital(mid6 pid3) --Account(mid7 pid1) -PublicMenu (mid8) --Home(mid9 pid8) --Register(mid10 pid8) --Login(mid11 pid8)

idk, that just doesn't seem cleaner but if that's better then hey, im game. I'm just going off of what my mind is spitting out.

[uaktags]

What about a separate class for the menu. Instead of using the hook like i did, creating a class and object that can be called via Smarty like {MenuManager->Load(Top_Menu_Admin)} where the MenuManager class, calls the Load function which parses are Menu groups for the Top_Menu_Admin or Top_Menu_Player or something like that. Then we could even create functions for it such as MenuManager->Add(Pid = 6 {(BANK's ID)}, "Deposit Money", ("Bank", "Deposit")) This Add function basically has the setup of Function Add ( parent_id = 0, title, args = 0) Parent_ID is always set to 0, but could be set to the Parent Menu's ID if it's a child menu Title is the Menu's Title Args are an array which the first parameter is for the Mod and the second is the Act, third and any after are other parameters being passed to that module

Since you have an Add function you should have a remove function as well. This way when a module is Uninstalled or Installed, the Add and Remove functions are called and no editing needs to happen to the TPL. This gives all the coding to be on the developers to make the modules work this way, and leaves the tpls for designers.

[uaktags]

I spent some time tonight and added to the installer on Devel the menu system as is. The hook system now opens up the following variables to be used in Templates: {Menu_UserMenu} : Home, EventLog, City, Account, Logout {Menu_WorldMenu} : Members {Menu_Admin_Menu} : Admin, Members, Back, Logout {Menu_LoggedOut} : Home, Register

Next I'll create a menu manager for the admin panel. Modules can populate these menus by the following means: A) Insert record to menu with id=Null, parent_id = 1, title = ModuleName, uri = "index.php?mod=ModuleName" This will add it to the top menu and be found whenever {Menu_UserMenu} is used. B) Insert new record to menu with id=Null, parent_id = Null, title = ModuleName, uri = "index.php?mod=ModuleName"

After I create the menu manager, I'm creating a separate class for menus like I mentioned in the above post so I can also build a recursive search for children. This will also allow us to open up the City.tpl and replace those "

" menus with actual dynamic menus that populate based on the installed modules.

[uaktags]

Okay, check out my new updates with the hooks/menu.php and func.menu.php. You now have the ability to have submenus. This doesn't just have to be for our top menus though. City.tpl can take them as stated earlier. This is probably the last of menus I'm going to focus on specifically for now. Next shall be to complete my module manager, link it with the menus, and then release the 1.0.3 with all my additions. Please, make additions, changes where need be or build a better system.

[uaktags]

Okay, last thing I need to do now is take away the database intensive dependency. What needs to happen (IMO) is load the menu db into an a single object/array 1 time and then just do all the checks and building off that 1 object so that there's only 1 call to db. That should take the weight off of the db and just on the normal processing.