When it is a custom application and we are starting from scratch it’s pretty easy. Together with our client’s end users, we set boundaries, discuss expectations and suggest the best implementation. When clients suggest an implementation that is not necessarily feasible or user-friendly, we will try to convince them on an alternative implementation that is more beneficial to both the client and end-user.

Migrations between technologies, on the other hand, are a different story. Let’s say from Oracle Forms to Oracle APEX. Migrating from Forms to APEX in most cases means rewriting parts of the application from the very beginning. Usually, it’s a good thing because it is the perfect moment to set new standards. Unfortunately, very often end-users don’t want to change their habits. When we attempt to migrate an application, we have to match the new version to the original as closely as possible. This approach implies a lot of trouble, especially when an application has a lot of actions that can be performed by the end-user in just one view.

Business case

Let us imagine logistics and shipping companies, which must organize their fleets and plan their freight transports. In the daily routine, end-users have to set routes for each vehicle, must assign drivers to vehicles, and manage other shipping and cargo related topics. If you were to try to visualize such a report, it would doubtless have a lot of columns. Let’s say that an example of such a report is as follows:

• vehicle (identification, status, capacity),
• driver (name, surname, mobile phone),
• starting point (country code and name, address),
• ending point (country code and name, address),
• notes,
• who is responsible for shipping.

That is a lot of information condensed into just one report. Now, imagine the number of actions that the end-user can perform from this view:

• edit, copy, delete shipping order,
• change driver or update current driver information,
• move the order to an external system,
• accept / decline order,
• add attachments.

Imagine a situation where you have more actions which are unique for each particular company because of their business logic. Just by adding those “default” actions to the aforementioned report we have an extra 9 columns! Of course, we can perform a 1-to-1 migration and recreate the application exactly as it was, but does that really help and improve the client’s business?

Convincing a client to change their approach to their applications is a big challenge (mainly because of the desktop-like features of Oracle Forms). Therefore we show clients applications that end-users are familiar with – Google Gmail, Facebook or Twitter. Those companies have created well designed and user-friendly applications used by millions of users around the world. At Pretius, good practices and a good User Experience are our top priorities and we put a lot of effort to provide end-users the best experience as we can.

So, let’s have a look at this screenshot from my Gmail account.

Buttons above e-mails report aggregate actions which function over the entire data set, in this case over all emails. Additionally, we can access the context menu on any row (via a right mouse click) to gain more granular control over individual data items (in this case individual emails). Everyone is familiar with such an approach – grouping actions and providing a row menu.

Native APEX approach

Fortunately, Oracle APEX has built-in support for a popup menu and at the official APEX demo page we can find a simple implementation guide.

There is only one small problem – the instructions in the guide describe an implementation which combines the popup menu with a unique, pre-existing APEX button.

Why this is the problem? Because of end-user demands that such a popup menu also be used in other places:

“That is what we need, but can we use it for report row too?”

Our answer, of course, is:

“Yes, we can”

John Snyders from the #orclapex dev team has already described a way to implement such functionality with reports in his blog post about using the APEX JavaScript menu API. But, as you can imagine, this is not the final requirement for a report row menu. Very often menu entries have to respect the following rules:

• display menu entries according to end-user privileges (entry authorization scheme),
• display menu entries according to session state (entry PL/SQL conditions),
• performed action is in the context of data in a row (open edit modal page with id from row),
• expose submenu with dynamic values dependent on current data in a row data.

Some of those requirements can be met using JavaScript menu API provided by Oracle, albeit at the expense of others.

For example, if we create a popup menu using solely the JavaScript API, we would lose the pros of using Oracle APEX list (declarative usage of authorization schemes). To overcome this issue we would need to evaluate and hold information about privileges in separate components within the page, all of which generates extra configuration.

It is possible but maintaining such a diffused configuration (JavaScript, dynamic actions, processes) for each report in an application would be a huge cost! Moreover, we don’t benefit from the biggest advantage of Oracle APEX – low code enclosed as components.

Pretius solution

Because of that, I’ve decided to combine those worlds together (popup menu based on APEX list and menu JavaScript API mentioned by John) by creating the next Pretius plugin for Oracle APEX. The plugin is available for Oracle APEX 5.1 and higher!

Pretius APEX Context Menu is dynamic action plugin implementing APEX popup menu based on defined APEX list. The plugin can be attached to any HTML element and renders entries according to authorisation scheme result. Menu entries can be extended by overriding behaviour, dynamically adding submenu and by adding new entries.

In the plugin live demo application, I have prepared an example popup menu on top of emp and dept tables. You will see 5 examples of how you can use the plugin to enhance your applications:

• checkbox menu to select checkboxes by report data,
• row menu respecting data logic within a row,
• dynamic context cell menu,
• breadcrumb menu attached to the APEX button (position fixed),
• contextual menu available only for one region.

If you are interested in learning more about those examples go to the “Description” tab in the live demo application and read the documentation at GitHub repo.

The plugin can be downloaded from apex.world – don’t forget to give it a like there!