What is a Menu system?

A menu system shows the user a list of available options so that one can be chosen to be activated. This list is usually broken down into a number of menu pages which are linked together in some sort of hierarchy.

When development of an application function has been completed the next step is to make it accessible to the users. As an application may be comprised of dozens, hundreds or even thousands of different functions, what is required is some sort of mechanism which presents the user with a list of available functions and allows one to be selected for activation/execution/processing. This is commonly referred to as a menu system. Presenting all available options in a single list is not considered to be a good idea, so the list is usually broken down into a hierarchy of smaller units or "pages". An option on any menu page may be an application function or another (sub) menu.

Some menu systems are "static" in that the contents of each page are hard coded and cannot be amended without changing program code. A "dynamic" menu system has a single page which initially is empty, but which obtains its contents from a database at run time. This then requires a set of maintenance screens which allow the menu details to be modified in the database without the need to change any program code. RADICORE uses a "dynamic" menu system which makes options available in two separate sets:

  • menu buttons - these are displayed in a row at the top of the screen where, after the user passes through a logon screen, the starting menu is defined on the user's primary role. This allows different users with different roles to start at different places in the menu hierarchy. If an option which is a menu is selected then the entire row of buttons is replaced. If an option which is a task (procedure or program) is selected, then the contents of the screen below the menu buttons will be replaced according to the requirements of that task. If a user switches to a different task using a menu button there is no information can can be passed from the current task to the new task which can be used as a filter.
  • navigation buttons - these are displayed in a row below the menu buttons and below the task description. Each task has its own set of navigation buttons. When a navigation button is pressed the current (parent) task will be suspended and the screen below the menu bar will be replaced according to the requirements of the selected (child) task. This will include changing the navigation buttons for those required by the new task. Information from the parent task, which is usually the table's primary key or a list of primary keys from those rows which have been selected, will be passed to the child task and used as a filter on the data which is retrieved by that child task.

Information in the application database is spread across a hierarchy of tables, and this information can be traversed using a hierarchy of tasks. A menu button will activate a task which starts at the top of a data hierarchy, and each child task activated from a navigation button will take the user to a lower or different level of detail.

Note that it is not necessary to create different sets of menu and navigation buttons for different users. There is just one set for everybody, but each user will be able to "see", and therefore select and activate, only those tasks to which they have been granted access. Access to different groups of tasks is given to Roles, and each user is then granted access to one or more of these Roles. This system is called Role Based Access Control (RBAC), and is a fundamental feature of the framework as it controls access to every task within every subsystem which is built to run under the framework.

The system used within RADICORE has a design document and a separate user manual.

Published: 09 April 2006