As time passes, multiple applications are created inside an APEX workspace. This often happens because we structure our solutions into separate applications per module, but also because we tend to create additional applications for prototyping and backups. If we add some utility applications that support the development process, the Application Builder can soon start to look something like this:

Like an average Windows desktop. Cluttered, making you lose time searching for the application you want to edit or run.

I’m not the most patient guy around, so I get frustrated quickly when I see someone moving their mouse around, trying to pick the right application. That’s why I decided to share with the community how I organise my APEX applications.

Application Groups

If my workspace has more than five applications, I start assigning them to Application Groups. You can find this feature under Workspace Utilities.

I prefix each group name with a number for sorting purposes and add a descriptive title that represents the associated applications.

I create application groups based on the environment or project context, but there are two groups I use consistently:

10 Development

This group contains all applications that are in active development. These are typically the applications most frequently accessed by developers.

If more than five applications are being actively developed, I split this group further — either by database schema or by functional area (for example: 10 Development Finance, 20 Development Inventory, …).

20 Tools

This group contains utility applications that support the development process. Some examples of applications I often use:

Master and template applications

With these two applications, I enable centralised management of Shared Components that are used across multiple applications.

The template application also contains configuration common to all applications. This way, I don’t need to set everything up from scratch when creating a new application. I simply create it as a copy of the template. By copying the application, Shared Component subscriptions to the master application are included automatically.

APEX Project Eye

This product by UNITED CODES is my companion on all development projects. We use it as a team to boost development productivity by extending application insights and enforcing Quality Assessments before delivering to the test environment.

DOME

This open-source utility, delivered by my colleague Zoran Tica, helps the team prepare installation packages and manage releases.

Project Management Applications

On some projects, we use our own custom application to manage work, in addition to classic tools like JIRA. Sometimes, we create advanced reporting on top of these tools by importing data from tickets using REST APIs

Other Application Groups

Other application groups vary from project to project. Here are some examples I’ve used in the past.

Prototypes and Sandboxes

These are playground applications used to try out new implementation concepts, prepare demonstrations, or redesign features without the risk of breaking the main applications.

Application Working Copies are also a valid option for such scenarios, but I prefer to use them primarily for new development.

Applications in this group should be removed regularly if they are no longer needed.

Published Applications

If applications are no longer actively developed, I move them to this separate group. This keeps the 10 Development group clean and focused, as developers don’t need to access these applications frequently anymore.

Education Materials

Applications which are used mainly for training sessions. I keep these applications because they are often helpful when onboarding new developers.

Backups and Snapshots

I don’t usually create application copies solely for backup purposes, but I often see workspaces cluttered with multiple copies.

I recommend removing all unnecessary copies and keeping only the latest or important milestone snapshots. For backups, I strongly prefer using Git repositories where application source code is exported and versioned.

That said, on a recent APEX migration project, I deliberately kept old application versions so we could compare behaviour and look before and after the migration.

Generated Applications

I created this group during an Oracle Forms to APEX migration project where we used PITSS.CON Forms2APEX Modeler to generate APEX applications based on Oracle Forms Code.

We typically keep the generated applications unchanged and copy relevant generated components into the applications under active development.

Private Report in the Application Builder

After creating application groups and assigning applications to them, I create my own private report in the Interactive Report on the Application Builder page.

Steps:

1. Switch from Cards View to Report View

2. Add the Group column

3. Create a Control break on the Group column

4. Sort primarily by Group, and secondarily by Application ID or Last Updated (based on preference)

5. Save the Report

After this, the Application Builder becomes much easier to navigate.

Page Groups

The same concept can be used to organise pages as well. This functionality is a bit more hidden and can be found under Application Utilities.

I use Page Groups in the majority of my projects instead of relying on page ID ranges, as I find them easier to manage and much more flexible when restructuring applications later on. I also use Page Groups when building custom reports based on APEX dictionary views (ie. grouping issues in Quality Assessments or analysing user activity reports)

As with Application Groups, I like to prefix Page Group names with numbers to control their ordering. My main functional modules are usually prefixed with 10, 20, and so on, while administration-related pages typically go under 99.

I would expect more native functionality in APEX around Application and Page Groups, especially when it comes to reporting capabilities and mass updates.

Summary

I always try to remove things I no longer need in my development environment and organise what remains in a meaningful way. If only I were as consistent with my things back at home, my wife would probably be a happier person 😅

I hope this tip helps you organise your Application Builder better and saves you a second or two every day.

This blog was inspired by a conversation with my dear colleague, Zoran Tica. While tackling a random technical challenge in Oracle APEX, we made the following assumption: there is no alternative for APEX_ITEM. I decided to investigate further to determine if this assumption holds true.

About APEX_ITEM

APEX_ITEM is a PL/SQL API that generates the HTML needed to add various types of input fields to your report regions. By looping through the returned records, you can process user input during page processing using custom PL/SQL code.

This API was widely used by developers to introduce interactivity into their reports or to support more dynamic, custom-built input forms. For example, the following region source:

SELECT
  apex_item.checkbox(1) sel,
  apex_item.hidden(2, empno) ||
  apex_item.text(3, ename, 'size=10') ename,
  job,
  apex_item.date_popup(4, rownum, hiredate, 'DD.MM.YYYY') hiredate,
  apex_item.text(5, sal, 'size=6') || ' €' sal,
  apex_item.select_list(
    p_idx         => 6,
    p_value       => deptno,
    p_list_values => 'ACCOUNTING;10,RESEARCH;20,SALES;30,OPERATIONS;40',
    p_show_null   => 'YES',
    p_null_text   => '-Select-',
    p_item_id     => 'f06_#ROWNUM#'
  ) department
FROM emp
ORDER BY empno;

would render like this:

and can be handled with the following PL/SQL process:

FOR i IN 1 .. apex_application.g_f01.count LOOP
  UPDATE emp
     SET ename    = apex_application.g_f03(i),
         hiredate = TO_DATE(apex_application.g_f04(i), 'DD.MM.YYYY'),
         sal      = apex_application.g_f05(i),
         deptno   = apex_application.g_f06(i)
   WHERE empno    = apex_application.g_f02(i);
END LOOP;

This API is marked as legacy

Many of us raised our eyebrows when the API was marked as legacy in the APEX 20.2 release.

This means the API can still be used, but it should not be used for new development. Existing applications will continue to work, as backward compatibility has always been a high priority for APEX. However, there are several reasons why you should consider replacing it:

• It bypasses important security features, such as XSS protection and session state protection.

• It sidesteps APEX’s validation and dynamic action framework.

• Its output is not aligned with Universal Theme styling.

Given how commonly it was used, you might have expected a clearly documented alternative, right? But until now, there hasn’t been an officially defined replacement.

That still doesn’t mean no alternatives exist.

As my colleague Zoran likes to say on (too) many occasions: “It depends.” And indeed, it really does depend on the use case.

Use Case 1 - Multiline editing

APEX_ITEM was one of the building blocks of the now-desupported Tabular Forms. These forms were the predecessor of the Interactive Grid when it came to multiline editing. So if you need a report where users can edit multiple records directly, then in most cases you should either:

• Use an Interactive Grid, which is the official successor to Tabular Forms, or

• Abandon multiline editing for the region and use a modal form page on top of your Interactive or Classic Report. I often see developers force multi-line editing instead of single record editing without any real business case behind it. Single record editing can be handled a lot more easily and is often more user-friendly and convenient to the end user.

Use Case 2 - Dynamic forms

Some developers used APEX_ITEM to generate input fields dynamically based on context — for example, flexible forms driven by product category or metadata.

APEX still does not offer a native, declarative equivalent for fully dynamic input generation.

If you need this pattern, one option is a commercial plugin:
FlowForms by United Codes
https://www.united-codes.com/ords/r/pip/flowforms/2

Use Case 3: Row Selection in Reports

I could be wrong, but my assumption is that in most cases developers use APEX_ITEM to add checkboxes to their Classic and Interactive Reports so they can provide row selection capabilities. That has certainly been the case in many APEX applications I have encountered.

For this use case, Oracle APEX now offers several native alternatives. Let’s take a look at the built-in options and walk through each one.

Dropdown Page Items with Multiselect

I know that using page items for multi-selection isn’t the same as selecting rows in a report. However, I’ve seen many scenarios where a simple multiselect dropdown solved the requirements just as well. And with recent APEX versions, the available options are actually quite good. Three page item types can serve as alternatives to a multi-select report.

The Popup LOV, which was redesigned in APEX 19.2, continues to improve in later versions. It is still the only item type that supports multiple columns in the inline dialog. Selecting multiple values can feel a bit cumbersome because the user has to reopen the dialog after each selection.

The Combobox item, introduced in APEX 23.2, handles multiple selection much more conveniently. The user can select multiple records directly by clicking the checkboxes. If records were pre-selected when the page was rendered, those rows are already marked as selected. The display value can also be formatted using HTML expressions and template directives.

The Select-Many page item type, introduced in APEX 24.1, is very similar to the Combobox. I had to look quite closely to understand the differences. Select-Many does not allow the user to add new values that are not part of the LOV source query, while the Combobox does. On the other hand, Select-Many is a bit more user-friendly because it shows a badge with the total number of selected records, and clicking that badge filters the list to display only the selected items.

For all three page item types you can define how the multiple values are stored in the session state. They can be stored as comma-separated values (for example: APEX,SQL,PL/SQL), which you can process with the APEX_STRING API:

select column_value from apex_string.split ( :ITEM_NAME, ',' );

Or they can be stored in JSON format (for example: ["APEX", "SQL", "PL/SQL"]), which you can handle using the JSON_TABLE SQL function:

select
    element
from
    json_table ( :ITEM_NAME, '$[*]'
        columns
            element varchar2 path '$'
    );

Interactive grid - row selector

In APEX 24.1 it became easier to use the native row selector in the Interactive Grid to achieve multiselect functionality. You can define the page item where the selected values are stored by updating the Interactive Grid’s Initialization JavaScript Function in the Attributes tab:

function( config ) {
  config.defaultGridViewOptions = {
    selectionStateItem: "P3_SELECTED_IDS",
    multiple: true
  };
  return config;
}

Template components

Declarative row selection options were added to Template Components in APEX 24.1. From a user experience point of view, this is similar to the Combobox and Select-Many items, but it allows for more customization and flexibility.

To enable row selection, you first define which column in the report serves as the primary key. After that, you can turn on row selection in the Attributes tab.

The only thing I am missing in Template Components is the ability to define column headers. Because of that limitation, Template Components may not be a suitable alternative when you need a multi-column report where you previously used APEX_ITEM for row selection. Without column headers, it is difficult to achieve a simple, traditional tabular layout.

When Is It Hard to Say Goodbye to APEX_ITEM

As mentioned earlier, APEX_ITEM is still very useful when you need to build dynamically generated input forms, and this is an area where native APEX features cannot fully replace it.

The same applies to dynamic reports. Sometimes you need to squeeze an input field directly into a column’s output, or conditionally show a checkbox only for certain rows. These patterns are difficult to reproduce with purely declarative components. Here is a simple example:

Region source:

SELECT
    CASE
        WHEN job = 'SALESMAN' THEN
            APEX_ITEM.CHECKBOX(1)
        ELSE
            NULL
    END AS sel,
    APEX_ITEM.HIDDEN(2, empno)
    || APEX_ITEM.TEXT(3, ename) AS ename,
    job,
    APEX_ITEM.DATE_POPUP(4, ROWNUM, hiredate, 'DD.MM.YYYY') AS hiredate,
    CASE
        WHEN job = 'SALESMAN' THEN
            sal || ' € --> ' || APEX_ITEM.TEXT(5, NULL) || ' €'
        ELSE
            sal || ' €'
    END AS sal
FROM emp
ORDER BY empno;

Conclusion

While it will be difficult to remove APEX_ITEM for every use case, it has never been easier to achieve row selection declaratively in Oracle APEX. In the past this was often a cumbersome task, but today the platform offers several native ways to handle it without falling back to APEX_ITEM. For row selection use cases, these options are more than capable, and I see no reason to continue using APEX_ITEM for that purpose alone. In most scenarios there is already a suitable replacement in the APEX toolbox.

You should definitely evaluate the alternatives and replace APEX_ITEM wherever possible, rather than burden your future self with legacy components.

That said, I am sure it will take time before APEX_ITEM disappears from our applications entirely. And unless the APEX team introduces a direct, one-to-one equivalent, it will likely remain present in legacy code for quite a while.

One of the wonderful things about Oracle APEX is that all the metadata of our applications is stored in the database and accessible through the APEX dictionary views. It would almost be a crime to avoid taking advantage of this for all sorts of possibilities.

We all follow coding guidelines or organizational policies to keep our solutions secure, consistent, and easy to maintain. Or at least we should follow them, but we all know this is only sometimes the case, especially in larger teams.

With APEX applications, it’s a walk in the park to validate if our standards are followed just by writing simple queries on the dictionary views.

Writing Quality Rules

Let’s take one commonly known security measure to prevent broken authentication in your application: Protecting your pages with authorization schemes.

If you want to check which pages are not protected with authorization schemes, you can just run this simple SQL statement:

select *
  from apex_application_pages
 where authorization_scheme is null

When looking at the results, we realize that it makes no sense to include publicly accessible pages like our login page, and also, page 0 cannot be protected with an authorization scheme. In the end, our statement should look something like this:

select *
  from apex_application_pages
 where authorization_scheme is null
   and page_id != 0
   and page_requires_authentication = 'Yes'

And this is how to get a list of all our pages that could cause an unnecessary security risk, so we fix them one by one. Easy right? But of course, it doesn't stop here. We could query to see if all our SAVE buttons are labelled and formatted consistently throughout the application if naming conventions are being followed, and all sorts of best practice guidelines.

Creating Quality Rules and Standards in APE

Not all developers are familiar with the APEX Dictionary views, and the library can be overwhelming. Also, running SQL statements one by one is time-consuming, so we want to validate our application code with a Quality Assurance framework that makes our lives even easier.

APEX Project Eye (APE) is one of a handful of available tools which can comprehensively support your Quality Assurance management.

With the Rule Builder Wizard, anyone who does not know all properties by heart can easily browse through the APEX dictionary views and get a preview of the most common values in their metadata to help find the correct attribute.

The Rule Builder generates the SQL statement for you with the component key attribute, which is the only required field for APE Quality rules:

Each rule can and should be described with its own metadata, giving the QA practitioner vital information about the rule, its justification, and steps to resolve the issue.

Quality rules are listed in Quality Standards, which represent your organizational guidelines, with a severity level for each rule defining how significant a violation of that rule is for you and your organization. And in case you lack some inspiration, APEX Project Eye delivers over 40 prebuilt rules included in the UNITED CODES Way of Working Quality Standards, which you can use or copy as templates.

Running Quality Assessments

Before running Quality Assessments, you need to define where the Assessments should be run and which Standards should be assessed. APE offers the following scope levels:

• Workspace

• Application

• Page Group

• Page

• Database Schema

It’s also possible to combine multiple scope levels:

After that, you're ready to roll! Sit back, relax, and wait for your assessment to finish.

Browsing Through the Assessment Results

When the assessment is finalized, you'll need to navigate a vast sea of found issues. APE helps you by offering three different browsing angles: By Rules, By Components, or By Severity:

And here are your issues waiting for you to analyze them and react as you see appropriate. You can mark the issue as an exception to exclude it from this and future assessments or immediately resolve it by clicking the Fix button, which takes you directly to the component in the APEX Page Designer.

Conclusion

Designing and aligning internally in your team which guidelines must be followed, can require quite some time and patience. But with a Quality Management Framework, it’s simple to implement and make QA Assessments part of your development lifecycle.

Useful links

APEX Project Eye