On 17 Jan 2007, at 8:21 AM, Earl Miles wrote:
-- path. This is not unique. It's often requested that one path could have more than one visible link. -- parent. If you omit this, it can be autogenerated but for setting it to some arbitrary value, let's say MENU_ROOT can be used to indicate a new menu. With this (or via other means if someone has a better idea) we can put links into any menu. -- title. -- weight. -- expanded. With path being unique in one and not unique in the other, I fail to see how the two could be unified. And I fail to see the point as well. We could lose path being an array key and make it a property again in hook_router as it was in old hook_menu but then what shall happen if someone defines two router items to the same path? This is a mess. The above is nice and clean. I think there are 2 paths involved in this. Menu path (where to display the link) and target path. I don't think there's a direct correlation between the menu path and the callback path, although it might default to that.
I think of the menu system as being a more evolved form of hook_link actually, which allows nesting. To me the key should be where it is displayed, and this might even include the menu it is being displayed in. This way it is easy for us to have an _alter hook, that allows us to change where menu items are. ie: $menu['node'] = array('path' => 'node', 'title' => 'Content'); $menu['primary:node'] = array('path' => 'node', 'title' => 'Home'); // two links to the same item, in separate trees. And then in menu_alter you could hide the elements ie: if ($menu['primary:node']) { unset($menu['primary:node']); // or $menu['primary:node']['type'] = MENU_DISABLED; } Maybe we should look at the similarities between hook_link and hook_menu some more.