Menu integration

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Menu integration
« on February 27th, 2012, 06:48 PM »
Having now integrated the admin panel stuff for simple cases, I'm inclined to think I should add something similar for the main menu - much as it's already possible to add actions without any hooks being called. The idea isn't to remove those hooks but to take out the most common use cases from being required (to lower the barrier to entry for basic stuff, without compromising more powerful stuff should it be needed)

Main menu tabs are a bit more complex than actions, because they need to cover things like permissions, so here's what I'm thinking. There would be a single cache of all the items, which is a nicely serialized array.

The XML would look like:

Code: [Select]
<menu_items>
  <language file="MyPlugin">
  <item name="myplugin" caption="my_plugin" icon="$pluginurl/myicon.png" permission="some_perm" url="$scripturl?action=myplugin" after="search">
    <item name="myplugin" caption="my_sub_plugin" url="$scripturl?action=myplugin;sa=blah">
  </item>
</menu_items>

This would create a new menu item, which would be highlighted on action=myplugin (due to the name), would use $txt['my_plugin'] as its caption (loaded from the plugin's MyPlugin.language.php file, and cached!), would have myicon.png as its icon, would only be visible if the user had some_perm permission, and when clicked would go to the given URL. Same deal for sub items.

As far as the caching goes, all that information would be cached, as well as - and this is the important part - when we created the cache and added an item, we'd also make sure to load all the different installed languages' files, to grab the entry/ies that we needed, and we'd cache them all in the menu. Since it's done at enable-plugin time, it should be relatively cheap to do.

The only problem I can imagine with that setup is that we might end up overflowing the serialize field if there's a lot of languages and a lot of menu entries added. Maybe this is a candidate for json_encode instead.

Also note we would definitely need to change the menu styling code as discussed before to create a single base class for each of the menu icons, such that each icon held to the same styling as far as padding etc. goes (and then this only has to worry about adding the icon itself, rather than having to worry about trying to add all the extra style code like padding)

Thoughts? (This one's primarily for plugin authors, though I'd appreciate your comments, Nao)
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

live627

  • Should five per cent appear too small / Be thankful I don't take it all / 'Cause I'm the taxman, yeah I'm the taxman
  • Posts: 1,670
Re: Menu integration
« Reply #1, on February 27th, 2012, 11:31 PM »
And to insert before, use the 'before' attribute?

Any equivalent for the 'enabled' key? Oh, wait, that would imply an eval().
A confident man keeps quiet.whereas a frightened man keeps talking, hiding his fear.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Menu integration
« Reply #2, on February 27th, 2012, 11:40 PM »
Yup, regarding before.

And no, no equivalent for the enabled key, unless it's done based on a $settings entry (and only a settings entry) being empty or not, e.g. enabled="somesetting" becomes 'enabled' => !empty($settings['somesetting'])

That to me doesn't seem worth the effort - if it's controlled by anything other than a permission, it's probably going to want to put a notice value in too, which says to me that it wants to be running its own hooked function anyway.
Re: Menu integration
« Reply #3, on March 13th, 2012, 12:34 PM »
Bump for the developers who would use this.