It’s time to toss that monstrosity and replace it with a menu system that is driven by database tables. This is not new and would not be too difficult as we already have js libs in house to allow for generation of trees from database tables (document categories, for instance), though a different more up-to-date library might be better.
The CSS style would be independent of the menu/tree structure and a UI to allow user to enable/disable/rearrange and add ACL would be a key. Could probably adapt one of the Gnome Menu edit tools that already exist for this.
The custom built menu sets could be provided as loadable SQL modules ….
I wholeheartedly agree. The side nav takes up too much valuable real estate. Menus would take up less space, and also allow a slightly more intuitive interface.
I don’t unserstand what you mean by “driven by database tables”. Could you give some examples of what menu names and items you would have that are “driven by database tables”?
If we get rid of the side nav, we need to use this space for side by side panes (this should be an option instead of top/bottom panes.
OK, I’m NOT recommending changing the way the LEFT Nav looks at all in this proposal. (that could happen too by someone that wants to do styling)
What I am recommending is storing ALL the information, menu selections, what they run, who can run them etc in a table called, say “menu_selections” so that they are not hard coded in the program and, therefore can be rearranged, added to or disable by ordinary users rather than programmers.
The current program is a mess of conditional if statements and styling code and is hard to read and hard to mess with.
Redesigning it would allow for more flexible styling as well as user configurability.
In the current left_nav.php there is an array($primary_docs) which manages some of the information for rendering the menu. However, it doesn’t capture enough information, hence the multi-level if/then to fully implement the navigation scheme. In order to fully implement a data driven scheme, we need to figure out what else needs to be captured in the database.
Each entry in $primary_docs array has a key which consists of an abbreviation that describes the menu item (but isn’t displayed anywhere) and then 3 entries,
1. Display text - (e.g. Calendar, Patient, Administration
2. Usage: which consists of an integer, 0, 1 or 2 which specifies “global”, “patient-specific”, “encounter-specific” so patient-specific and encounter-specific menu items are only enabled when a patient and an encounter have been chosen respectively.
3. Relative URL of the page to display
Stuff that’s Missing
1. The organization of the menu, (order of items, parent/child relationships). All of this is hard coded, the menu “sequence” is defined currently by the order in which genTreeLink,genMiscLink,genPopupLink (etc.) is explicitly called in the .PHP
2. Access Control. For functions that need to be restricted the acl_check happens before the genXXXLink function is called
3. Different behavior based on “Normal” vs. “Athletic Team” vs. “IPPF”. Depending on the status of the IPPF and Athletic teams flags the menus are rendered/displayed differently. I’ve never set those flags so I can’t describe what the differences are, but I know that there are tests for that in the left_nav code. It’s possible that we can handle the differences as an extension of the ACL checks, but I’m not really sure.
Anything else folks can think of that needs to happen to make this work?
Also missing.
4. Definitions for “Headers”: $primary_docs doesn’t describe the section headers/grouping labels in the menu. These are currently brought in as hard coded HTML.