Menu system plan

Background

Currently the menus are hardcoded in separate controller files. The views that are related to the menus loop through a simple array with the menu items title's and url's. This solution is not flexible, is impossible for an administrator to manage and doesn't allow for nested, hierarchical menus.

Long term goal

The long term goal for the menu system should be to create a completely dynamic hierarchical system where it is possible for an administrator to click and drag to move menu items around. An administrator should also be able to create new menus and menu items. The administrations tasks will require quiet a lot of UI coding though, which is not the main goal of the project. Therefor the main focus should be on allowing 3rd party developers to add and remove menu items.

Although the current menu implementations do not use hierarchical menus, it would be a good idea to plan ahead since that is a critical feature to allow theme developers to create custom themes and a user-friendly, well-structured site.

Plan of action

The development will need to be done in iterations. When all iterations are finished I hope that we will have a system with clean and structured url's. To achieve this some work needs to be done on how pages are being displayed.

Today, pages are loaded as individual php files that are located by a URL. Some pages make use of GET parameters in the URL. To be able to create a dynamic menu, with any number of pages while at the same time maintaining some kind of sane URL structure we will have to work with the index.php files in the root and admin folders.

These php files will take arguments from the URL and query the database for which page to load that matches the given argument. For example the URL http://www.hackademic.dev/?page=/dir/subdir/page will have a row in the database with the page column /dir/subdir/page and file column /user/plugin/custom-plugin/some-page.php. The index.php file will then include this file which then might launch a controller or do whatever the custom-plugin does.

The menu item table must also contain permissions since some menu items are not supposed to be visible to all users.

First iteration

The first iteration will simply move the current user menu from the UserMenuController into the database. The structure of the database will be as follows:

-------------------
|Menus
-------------------
|id (PK)| |display name|
-------------------

--------------------------------------------------------------
|Menu items
--------------------------------------------------------------
|page (PK)| |mid (PK)| |permission (FK)| |label| |file| |sort| 
--------------------------------------------------------------

-----------------------------
|Permissions
-----------------------------
|id (PK)| |permission| |role|
-----------------------------

Note that we lack a roles table since roles are hard coded into the Session class. I still think this is a good solution since it will allow for easy implementation of a roles table in the future. For now, permissions will be inserted into the database on installation.

This iteration should allow a 3rd party dev to add menu items and display them. It will take place in sprint 4

Second iteration

The second iteration will focus on the hierarchy of the menus. A new column parent will be introduced in the menu_items table.

-----------------------------------------------------------------------
|Menu items
-----------------------------------------------------------------------
|mid (FK)| |label| |page (PK)| |file| |sort| |parent| |permission (FK)|
-----------------------------------------------------------------------

To allow for hierarchical menus, the view code will have do be rewritten to acommodate nested elements. The loops that produce the menu's will have do dig deeper into the menu array and some CSS will have to be written to hide/show sub-items.

When this iteration is finished, a 3rd party dev should be able to re-order menus and add sub-items that are displayed. At the moment, this work is planned for sprint 5 unless something else comes up.

Third iteration

There might not be enough time to start on this iteration. It would contain the creation of the administration interface so that an admin can manage the menus. For now, it is more important to enable the possibility to change the menus for developers. Until the UI is finished, administrators can use code if they want to change menus.

This could be useful in the ui development: http://www.drakedata.com/serializetree/sampleTree.html