Menus and Contexts - A Discussion

[lonnieezell]

One of the last areas that I want to look at for 0.7 is a complete redo of how the menu system works. I've become disillusioned with the way the Contexts currently work, to add menu items to the system. While the automatic nature of it is nice, I feel it's too restricting, and have found myself dreading just having to add an item to the menu. That's crazy. :) So here's my thoughts, but I'm unsure of the best way to handle this.

First - I want to strip most of the magic away. I had thought about completely removing any form of navigation system altogether, and letting it simply be people adding it to their HTML. Which works fine for many instances, especially the front end that they'd be developing. It breaks down in the admin area with modules it seems, especially if we want drag-and-drop module capabilities, which I would like to have happen.

The next thought was that we'd make a full-fledged menu manager, like Drupal or WordPress. I even started down that road during the rewrite I had started. There's problems with this, though, in that it's more intricate code to maintain, it's complex to make it so that modules can add their own things on menus (like Wordpress does, and is something that would be needed in this system to really work well), and it's extremely difficult to version the menu of a site between the dev, staging and live sites when it's all done through a GUI in the backend.

That leaves us with a file-based system. The more I've thought about it, the more I can see this working, but I wanted to get everyone's input on this.

• Menus are stored within a new folder, application/menus.
• Each menu has it's own separate .json file that defines the structure of the menu. It can support auto-replacing the SITE_AREA variable, and some other meta tags to help it deal with some of the routing issues.
• We can incorporate the idea of the Contexts in a couple of ways still.
  • First, we could have a replacement variable for the contexts that will search through all of the modules, and pull in their menu items much like we do now.
  • We could even have a first-level tag that basically re-creates the menu for a single context in the exact same way we do now.
• Once a menu has been built, it is saved to the cache system. This negates any performance issues.

A couple of the main reasons for doing this are:

• Versioning of menus between environments
• Ability for a module to add a completely new menu (which was very difficult previously)

What does everyone think? Am I completely off base here?

[lonnieezell]

I forgot to mention that this would then include a library that would allow the template system to easily display menus via a {menus:display name="xxx"} type of tag, as well as the traditional straight PHP version $this->menus->display('xxx');.

[christoferd]

JSON works fine for one simple app I have running. Makes it very quick to edit the menu. Also, as it's PHP it allows me to filter what to show depending on group & permissions.

Being able to customize menu and per group/user role is important. Same with side menus.

Automation is still very handy. Add a flag to Controller to be able to disable auto menu item?

Note, if there is more than one point that affects menus, IMO it will be tough on developers, sooner or later.

Cheers, Chris

On 26 August 2013 13:15, Lonnie Ezell notifications@github.com wrote:

I forgot to mention that this would then include a library that would allow the template system to easily display menus via a {menus:display name="xxx"} type of tag, as well as the traditional straight PHP version $this->menus->display('xxx');.

— Reply to this email directly or view it on GitHubhttps://github.com/ci-bonfire/Bonfire/issues/872#issuecomment-23241943 .

[feelnopain]

I would really like a menu system, it would make development so much easier

[mwhitneysdsu]

I would love to see a menu system that could work for both the front- and back-end of the site. As it stands, I have a completely separate module to build the main menu on my site (and I'm thinking about adding some caching to it, but I was going to test caching the HTML fragment in the database vs. the file system).

My primary concerns are:

• Making sure the cache is updated when the menu is changed
• Making sure the cache recognizes role-based authorization (at a minimum)
• Not requiring additional work to generate basic menu entries on the back end

On the back-end, if I need a more complex menu, I usually focus on the sub_nav, so the user can get straight to the module, then move around within that module. Granted, for the developers/admins the Content menu is unwieldy at the moment (with 39 entries), but none of our users are even close to having access to as many modules, and we'll eventually weed out the items that don't belong there (some of our early code spread out across multiple modules when it shouldn't have, or modules are being consolidated by refactoring).

[lonnieezell]

Here's a quick docs of what I'm thinking. It's not complete, but should get the initial idea in place. Does this address the issues or is it still missing something? Does everyone think it will work?

https://gist.github.com/lonnieezell/6346091

[mwhitneysdsu]

What I'm thinking (not an opinion on whether it will work, because it can work):

• I only like editing files for exceptional cases, I can always use a migration for a change that needs to be portable, but being able to update my front-end menu through a module's Settings context has been a life-saver for me on occasion
• The more complicated the menu, the more difficult it gets to maintain a file
• Modules should be self-contained to the largest extent possible

The system could:

• take the content of application/menus and
  • merge the content of the menus folders in the modules into a cached set of menus, and
• each cached menu could contain properties that would help trace the source of the menu items, or
  • some other method of easily tracing the source of the items
• any given menu could contain one or more other menus (i.e. you might define the 'admin' menu as a simple menu containing the 'content', 'reports', 'settings', and 'developer' menus)
• allow definition of conditional build-out of default menu entries if a module doesn't override the menu (so, if /application/menus/content.json defines a conditional build-out of a Module_name menu entry when the user has 'Content.Module_name.View' permission and the Module_name Content controller exists, the Module_name entry is added to the menu unless the module also defines menu entries in /modules/Module_name/menus/content.json)
  • this might look something like:

{
  "name": "Content",
    "description": "Admin Content Context menu",
    "restrict_permission": "Site.Content.View",
    "cache_life": 86400,
    "items": [
        // Maybe we want some entries before/after the generated list
    ],
    "rules": [
        "permission": "Content.{module}.View",
        "route_exists": "admin/content/{module}",
        "items": [
            {
                "name": "{module}",
                "description": "{module} Admin Content Context menu",
                ...
            },
             ...
        ]
    ]
}

[christoferd]

Lonnie, Info features in your Gist sound great to me. +1 : )

On 27 August 2013 18:27, Mat Whitney notifications@github.com wrote:

What I'm thinking (not an opinion on whether it will work, because it can work):

• I only like editing files for exceptional cases, I can always use a migration for a change that needs to be portable, but being able to update my front-end menu through a module's Settings context has been a life-saver for me on occasion
• The more complicated the menu, the more difficult it gets to maintain a file
• Modules should be self-contained to the largest extent possible

The system could:

• take the content of application/menus and
  • merge the content of the menus folders in the modules into a cached set of menus, and
  • each cached menu could contain properties that would help trace the source of the menu items, or
  • some other method of easily tracing the source of the items
  • any given menu could contain one or more other menus (i.e. you might define the 'admin' menu as a simple menu containing the 'content', 'reports', 'settings', and 'developer' menus)
• allow definition of conditional build-out of default menu entries if a module doesn't override the menu (so, if /application/menus/content.json defines a conditional build-out of a Module_name menu entry when the user has 'Content.Module_name.View' permission and the Module_name Content controller exists, the Module_name entry is added to the menu unless the module also defines menu entries in /modules/Module_name/menus/content.json)
  • this might look something like: javascript { "name": "Content", "description": "Admin Content Context menu", "restrict_permission": "Site.Content.View", "cache_life": 86400, "items": [ // Maybe we want some entries before/after the generated list ], "rules": [ "permission": "Content.{module}.View", "route_exists": "admin/content/{module}", "items": [ { "name": "{module}", "description": "{module} Admin Content Context menu", ... }, ... ] ] }

— Reply to this email directly or view it on GitHubhttps://github.com/ci-bonfire/Bonfire/issues/872#issuecomment-23320312 .

[lonnieezell]

Work is well under way on this library. I'm working to make it usable within any CI-based project, not just Bonfire, so it's being hosted separately at https://github.com/lonnieezell/menus.

It currently handles standard menu files, menu items, reading in other menu files, building menus from our notion of Contexts.

There are a few features that still need implementing like:

• providing callbacks to handle Authorization when rendering the menu.
• allow for "separator objects" in menus.
• a few more css classes/objects to allow for all of the features of Bootstrap. (Eventually would like to make simple settings templates to get it ready for Bootstrap 2.x, 3.x and Zurb's Foundation.

Please give it a play (and help out if you have the time!)

[q--]

Looking at how the current config.php of a module is structured, could it be an option to allow menu configuration like the following?

PHP

$menus = array(
    'admin' => array(
        'top_level_menu_item' => array( //In the current code, this would be the name of a context
            'default' => 'default_url', // Is used if there are no submenus
        ) ,
        'another_top_level_menu_item' => array( //In the current code, this would be the name of a context

            // No need to define a default URL here, since it's already known there are sub menus

            'submenu_1' => array(
                'default' => 'default_url', // Is used if there are no submenus
            ) ,
            'submenu_2' => array(
                'sub_submenu_1' => array(
                    'default' => 'default_url'
                )
            )
        )
    )
);

Output:

[Gyvastis]

I think q-- has a good option in mind. I mean, there is no need to implement JSON. PHP arrays would be fine and storing them in a config file, alongside other configs would be great for the start. Though the management of menu should not bet overlooked. As far as I can see right now, there are two options. Eather we make an editor of the menu in the setting area and parse-save it so the config file, but in my opinion, that's too much. And the other option is to drop the array idea and just as we implement the editor for menu, we simply save it to database, that's the simpliest for the most part. Of course using library would make more sense, but it's bonefire, it should make the management easy, from that point we should really think of an editor, reachable in settings menu context. Basically a new, system-wide module.

[q--]

In my idea, the order of menus per module could be controlled by the order they are in the array. If the order also needs to be configurable independently of the module (if two modules add items to the same menu), perhaps an editor is the best option. Anyway, I thought of this so modules could be somewhat like "extensions", such as the ones you install into Firefox and which then can add items to any menu in the program. Mainly, this avoids:

1. Having to load even more files, the admin area of Bonfire is quite slow already. (Caching can help with this, though.)
2. Having to either create different a module for each menu item or tamper with the Bonfire core.
3. Having to configure a menu for every module you install.