The Audit section captures key metadata about each component in your APEX application. Specifically, it records:

• Changed By: The username of the last developer who modified the component.

• Changed On: The timestamp of the last modification.

This information is automatically tracked by APEX and displayed as read-only fields within Page Designer and other areas of the Application Builder. Like most metadata in APEX, these audit details are also available through the APEX dictionary views.

When exporting an application, you can choose whether or not to include audit metadata. This is especially important if you're using version control:

• Excluding audit info can reduce noise in version diffs, making it easier to track real functional changes.

• Including audit info might be useful in simpler setups to retain a lightweight, built-in form of change tracking.

You can configure this in the Export Application dialog under the "Include Audit Information" section. Options include:

• None (default) – No audit information is exported.

• Dates Only – Only timestamps (Created On, Changed On) are included.

• Names and Dates – Both usernames and timestamps (Created By, Changed By, etc.) are included.

This setting lets you strike the right balance between traceability and clean version control depending on your development workflow.

Enjoy life!

Configuration

In the configuration section, you can set the Build Option attribute—an often overlooked but powerful feature in APEX. It lets you enable or disable components or groups of components dynamically.

Some practical use cases from the official help include:

1. Multi-installation apps: Develop one app and use Build Options to tailor functionality per installation, allowing privileged users to toggle features on or off.

2. Incomplete features: Hide unfinished functionality in test or production environments without removing the code, enabling safe deployment.

3. Safe removal: Temporarily disable features you’re unsure about (“comment them out”) and easily restore them if needed before permanent removal.

Some of these cases are built into APEX by design. For example, the “Commented Out” build option is an excluded option that lets you temporarily disable a component—useful during debugging or before deprecation. To apply a build option, simply select the desired option for the component. By default, APEX presents both the option and its negation for easy toggling.

A shortcut for this specific case is available in the context menu of any component in Page Designer — just right-click the component in the rendering tree to quickly set its build option.

For this case, behind the scenes, APEX automatically creates the build option for you when creating an application through the wizard. If your application is from an older export, you can manually create the build option with the same name under Shared Components to gain access to that shortcut in recent versions of APEX.

Another example of implementing a build option is with feature pages. You might recall the built-in features that come with APEX:

Most features include a build option designed to support the first use case—tailoring functionality for each installation. You can test this by enabling a specific feature and checking the results in the Build Options section of Shared Components.

Just like with authorization schemes, before assigning a build option to a component, you first need to create and configure that build option under Build Options in the Application Logic section of Shared Components.

Remember, you can quickly access the Create Build Option wizard directly from Page Designer, under the Shared Components list, as shown below:

When creating it, you set its status, which controls whether the related component or process will be:

• Include: Rendered or executed

• Exclude: Skipped and not rendered or executed

You can also set two additional attributes that simplify your deployment process, especially when working with packaged applications:

• Default on Export: Sets the build option’s status when the application is exported.

• On Upgrade Keep Status: Determines whether the build option status in the deployed application should be preserved or overwritten during an upgrade. Selecting On to keep the deployed status is useful if your application uses the APEX_UTIL.SET_BUILD_OPTION_STATUS API to dynamically manage build options and you want those settings to remain intact after upgrading.

A particularly handy feature in APEX is the Utilization Reports, available on most Shared Components pages. In this case, you can use them to see which components are affected by a specific build option configuration.

And once again, there are APEX Data Dictionary views that can help if you want to access this information programmatically. Here’s an example showing how to list all existing build options, which you can filter by application or workspace:

select * 
from apex_application_build_options

Or use this example to identify all the views where build options are available:

select * from apex_dictionary
where column_name like '%BUILD%'

Enjoy life!

The Comment attribute might be one of the most universally available fields in Oracle APEX. It allows developers to quickly leave notes or remarks—for themselves or for teammates—that are never shown to end users during runtime.

You'll find the Comment field at nearly every level of the application: pages, regions, items, reports, shared components, and more.

Unfortunately, in practice, this attribute is underused—just like code comments often are in traditional development. We've all heard the phrase “the code is the documentation”, but in the world of low-code, there's often not much code to speak of! 😄

So, the Comment attribute becomes a valuable space to capture important context, design decisions, or reminders directly where they matter most—inside the metadata.

Make it a habit: your future self (or teammate) will thank you.

Again, since these comments are stored as metadata in the APEX dictionary, you can easily access them using SQL queries. For example, if your team has a convention to mark ToDo tasks within comments, you can quickly generate a report of all outstanding action items like this:

SELECT
    application_id,
    page_id,
    item_name,
    component_comment
FROM
    apex_application_page_items
WHERE
    application_id = :app_id
and lower(component_comment) like '%todo%';

Last but not least, when exporting your application, you have the option to include or exclude developer comments right from the Page Designer export settings.

In the export options, you’ll find “Include Developer Comments” with two choices:

• On: Developer Comments are included in the application export.

• Off: Developer Comments are excluded from the export.

This gives you control over whether your internal notes travel with your application files—helpful when sharing with others or managing version control.

Enjoy life!

Although often overlooked, the Help attribute plays an important role in improving the user experience by providing clear, contextual guidance right where it’s needed.

Whether you're building internal tools or public-facing applications, leveraging this feature effectively can reduce user confusion and support requests.

Help

As the name suggests, the Help sections in Oracle APEX provide a built-in mechanism for developers to define help text for various components. This information is processed and made available to end users in different ways, depending on the type of component.

Once again, the entered information is stored in the APEX metadata schema, which means that any changes to the help text will require a redeployment to propagate those changes to other environments.

For small applications, this feature is very convenient—it simplifies your life by keeping everything within the APEX builder. Help texts are automatically exported and included in your application deployment, so there's nothing extra to manage.

These help text strings are also available for translation in multi-language applications, making it easy to provide localized guidance for users in different regions.

However, in more complex or enterprise-level solutions, you might prefer to implement a custom help system—for example, storing help content in database tables—so that updates can be made dynamically without requiring a full redeployment.

Page-Level Help

For page-level help, the content entered by the developer can be retrieved at runtime using the HELP procedure in the APEX_APPLICATION package. This gives you control over how and when to display help content to users.

For example, a modal dialog page—accessed via a button in the navigation bar—could include a Dynamic PL/SQL Region that displays the help text defined by the developer for the current page. This can be done using a call like the following:

APEX_APPLICATION.HELP(p_flow_id => :APP_ID);

More details can be found in the APEX API documentation.

Setting Page Help

Unfortunately, there is no official setter procedure exposed in the public APEX API to update page help text programmatically.

If you want to enable power users to edit page help dynamically, you may need to rely on undocumented procedures.

Item-Level Help

For items, APEX provides two distinct attributes:

• Inline Help Text

• Help Text

As the attribute descriptions suggest:

• Inline Help Text is displayed directly next to or below the item. It provides immediate, field-level guidance, which is particularly useful for improving accessibility or offering quick hints.

• Help Text (the "old" style) is shown on demand—typically when the user clicks the help icon next to the item. This is ideal for more detailed or contextual explanations that don't need to be always visible.

Because of this visual distinction, developers often use a short, concise message for inline help and reserve longer, richer content (potentially including HTML formatting and substitutions) for the help dialog.

Note: Help text fields support HTML and dynamic substitutions, including application, page items, and system variables.

Retrieving Help Text from the Data Dictionary

Like most metadata in APEX, help content is stored in the APEX dictionary views and can be queried. For example, to retrieve item-level help information, you can run:

SELECT application_id,
       page_id,
       item_name,
       display_as,
       item_help_text,
       inline_help_text
FROM apex_application_page_items
WHERE application_id = :APP_ID;

The same applies to page-level help texts:

SELECT application_id,
       page_id,
       help_text
FROM apex_application_pages
WHERE application_id = :APP_ID;

Enjoy life!

And because there are specific security-related attributes at both the page and item levels, I’ll be covering those here too for a more complete picture.

Security

In the Security section of a component's attributes, you may encounter different security-related options depending on the type of component you're working with. However, one attribute is common to all component types: the Authorization Scheme.

This attribute allows you to control access to a component by selecting a predefined authorization scheme—or its negation— meaning the component will be rendered or executed only if the user does meet the criteria defined in the scheme.

Unlike the Read-only attribute, which can be overridden by a child component, the Authorization Scheme and Server-Side Condition attributes are enforced at the parent level and cannot be bypassed or redefined by child components.

Authorization Scheme

Before assigning an authorization scheme to a component, you must first define it under Authorization Schemes in the Security section of Shared Components. Each scheme includes a logic block (typically PL/SQL or SQL) used to determine whether the current user meets the specified condition.

A key aspect to understand here is the Evaluation Point, which determines when and how often an authorization scheme is evaluated during a user session. As per Oracle's documentation:

• Once per session: The scheme is evaluated only once per session, and the result is cached for all future uses.

• Once per page view: Evaluated once per request. If the same scheme is used in multiple components on the same page, the result is reused.

• Once per component: Evaluated individually for each component using the scheme, but results are cached in the session for reuse across requests.

• Always (No Caching): The scheme is evaluated every time it is referenced—no caching occurs.

Choosing the right evaluation point can have an impact on both performance and security, so it’s important to consider how dynamic your access rules are and how often they might change within a session.

You might be wondering—and rightly so—how authorization schemes differ from server-side conditions, since both are used to control component visibility or execution. While they may seem similar at first glance, authorization schemes serve a slightly different purpose and operate at a higher level.

Authorization schemes are typically centralized, reusable conditions that can be assigned to multiple components across your application. They support caching, which improves performance by avoiding repeated evaluations. This makes them ideal for access control scenarios, such as role-based restrictions, where the logic doesn't change frequently within a session.

On the other hand, server-side conditions are always evaluated at runtime, every time a component is processed. This behavior is functionally equivalent to setting an authorization scheme to "Always (No Caching)", which disables caching altogether.

If you're interested in server-side conditions, check out the previous blog post dedicated to that topic.

Keeping the number of authorization schemes at a reasonable level is key to maintaining long-term control and clarity in your Oracle APEX application. If you create too many narrowly scoped schemes—essentially micromanaging access—you risk creating a tangled web that’s hard to maintain. On the other hand, using only a few overly broad schemes might not give you the granularity needed for complex applications.

A good compromise is to design modular, reusable authorization schemes—but also build in a way to reset their cached results when necessary.

Let me explain with an example.

Imagine you’re building a project management application, where users can take on different roles in different projects (e.g., Manager in Project A, Viewer in Project B). To support this, you might have a select list that allows users to switch between projects, storing the selected project ID in an application item like AI_PROJECT_ID.

Now, suppose you have an authorization scheme that determines what a user is allowed to do based on their role in the selected project.

sample_security_package.auth_is_user_pm(
    p_username    => :APP_USER, 
    p_role_code   => 'PM', 
    p_project_id  => :AI_PROJECT_ID);

Since authorization schemes can cache results (depending on their evaluation point), you might run into a situation where the cached result doesn't reflect the newly selected project—because the scheme was already evaluated earlier in the session.

To solve this, you can manually reset the authorization cache when the user switches projects. This ensures that the next time the scheme is evaluated, it runs fresh with the correct context.

You can achieve this by calling the following built-in procedure:

APEX_AUTHORIZATION.RESET_CACHE;

Page specific attributes

Oracle APEX allows certain security settings, usually defined at the application level, to be overridden at the page level. This gives developers fine-grained control over how individual pages behave in terms of access, caching, and session protection.

Authentication

Determines whether a page requires authentication or is publicly accessible. One of the first things APEX does when generating a page is check whether the user is allowed to access it. This is handled by the Page Sentry function, which validates key security aspects such as the username, session validity, and more.

If the check passes, page generation continues; otherwise, the user is redirected to the URL defined in the "Go To" attribute of the authentication scheme in use.

While it's possible to define a custom Page Sentry function, it’s generally not recommended unless you have a very specific security need.

Deep Linking

Conceptually, deep linking allows users to "land" directly on a specific page within an application's flow, often with pre-set page items passed via URL parameters.

For example, in an email marketing campaign, your call-to-action might link to a specific APEX page. Each recipient could receive a dynamically generated URL that sets user preferences via parameters—ensuring the page displays personalized content that matches the email context.

In enterprise applications (where APEX is often used), you might want users to go directly to an Approval Request page, loading for instance REQUEST_ID=1234 via the URL so they can immediately approve or reject it.

If this attribute is disabled, APEX will ignore and strip out any parameters passed in the page URL.

If enabled, and a valid APEX session exists, the page will load directly with all URL parameters preserved.
If the user isn’t authenticated, they’ll be redirected to the login screen first. After successful login, APEX will take them to the originally requested page, with all parameters intact.

This setting only applies to external requests. Internal navigation within the application is not affected by the Deep Linking setting.

By default, Deep Linking is disabled at the application level under the Security section in Shared Components. However, to simplify development, Deep Linking is always enabled when the user is logged into the APEX development environment.

It’s also important to note that if the target page’s security settings require a checksum for arguments, a valid checksum must be included along with the parameter values.

In scenarios like the email example, you’ll need to use the older API function APEX_UTIL.PREPARE_URL to generate the link URL, which allows you to explicitly define the type of checksum required. The newer APEX_PAGE.GET_URL function does not offer this level of control, making it unsuitable when protected items are involved.

Page Access Protection

Page access protection determines whether a request can render the page, whether it can set the values of page or application items, and under what conditions, such as requiring a checksum. The available options are:

• Unrestricted: The page can be accessed via URL with or without session state arguments.

• Arguments Must Have Checksum: URL arguments require a checksum to ensure security.

• No Arguments Supported: The page can be accessed via URL but without any parameters.

• No URL Access: The page can only be accessed internally (e.g., via branches), not by direct URL.

Let’s focus for a moment on the second option, “Argument must have a checksum.” This default option instructs APEX to recalculate and validate the argument values against the provided checksum to ensure that users cannot manipulate the values. This attribute is related to the item security setting, “Session State Protection,” which dictates the type of checksum required for that specific item.

When generating a link to a specific page, APEX checks the target page and its item configuration to generate the correct checksum value. For example:

p3_empno=7566
clear=3
session=11155673235579
cs=1aGnPAKiqEoe1HtNuF.......OhLVhVG2cVLQwl4B84d

If you look closely at the arguments passed in the URL, you’ll notice that in this simple example, the page item P3_EMPNO is set to 7566 and the Clear Cache is set to 3. Behind the scenes, APEX adds a third argument, likely called cv (Checksum Value), which is a hash generated from the page and item values. When the page executes, APEX recalculates this hash to verify that the passed values haven’t been tampered with.

Form Auto-Complete

Enables or disables browser auto-complete on form fields. Setting this to Off adds autocomplete="off" to the HTML form tag. Behavior may vary across browsers.

As per MDN, the HTML autocomplete attribute lets web developers specify what if any permission the user agent has to provide automated assistance in filling out form field values, as well as guidance to the browser as to the type of information expected in the field.

Browser Cache
Controls whether the browser can cache page content:

• Enabled: Allows caching in memory or on disk.

• Disabled: Sends the cache-control: no-store header to prevent caching—recommended for security.

• Application Default: Inherits the setting from the application-level security attributes.

Oracle recommends disabling browser cache for pages displaying sensitive data, to avoid the risk of viewing stale content after logout via the browser's back button.

Items specific attributes

In the case of items, apart from the already mentioned generic Authorization scheme, we can set three additional attributes, two related to session state and one related to data sanitazion:

Session State Protection

Oracle APEX provides granular control over how page items handle session state and URL-based data submission through the Session State Protection attribute. This setting determines the security level for each item, helping prevent unauthorized data manipulation via URLs or forms.

• Unrestricted

• Checksum Required – Application Level

• Checksum Required – User Level

• Checksum Required – Session Level

• Restricted – May not be set from browser

The first and last options are straightforward. Normally, items where the user is expected to enter data are set to Unrestricted. This must also be the case for hidden or display-only items that are dynamically populated after page rendering. For example, you might use the additional output of a Popup LOV to fill display-only fields. If a user selects a 'restaurant' record from a list, the corresponding full address could be automatically populated so it can be submitted and processed later.

Restricted, on the other hand, is suitable for items that are computed or fetched during page rendering and are not intended to be modified by the user. In my experience, this setting is rarely applied at the page level but is commonly used for application items that are precomputed at the start of a session and control application behavior.

The other three options relate to checksums. They instruct APEX to validate that the argument passed corresponds to the checksum value, ensuring data integrity when fetching and rendering the page. These options allow you to control the security level of the checksum:

• Session Level (default, most secure): The checksum applies only to the current session. This is ideal for forms triggered from a record in a report within a valid user session.

• User Level: The checksum is valid as long as the application user is the same. This is useful when a user wants to save a bookmark to a specific page with arguments to access later.

• Application Level (least secure): The checksum is valid for any user of the application. This is typically used for email links, where multiple users might access the page with the same arguments. In this case, it’s advisable to add an extra security check to ensure that the user has the proper rights to view the record.

Store value encrypted in session state

This attribute is straightforward—it lets you encrypt the item’s value when stored in session state. If the item contains sensitive data, enabling encryption ensures that the value is protected in APEX’s session state management tables.

Without encryption, anyone with access to the APEX metadata tables could potentially query and retrieve this sensitive information.

As mentioned, APEX is secure by default, so this feature is enabled automatically.

Restricted characters

This attribute allows you to declaratively sanitize values submitted by the user. As a developer, you may recall the first security rule: “never trust the user.” Out of the box, APEX supports a limited set of parameters for the escape function, which include:

• All characters can be saved

• Allowlist for a–z, 0–9, and space

• Blocklist HTML command characters (< > ")

• Blocklist & < > " / ; , * | = % and --

• Blocklist & < > " / ; , * | = % or -- and new line

For example, if you configure it to allow only letters and numbers, APEX will raise an error whenever the submitted value contains any other characters.

If these options don’t meet your needs, APEX—as always—gives you full control over your settings. In this case, the APEX_ESCAPE package allows you to sanitize and escape user inputs with greater granularity. You can find the full documentation here.

Enjoy life!

In the first post, we looked at the Server-side Condition attribute and how it influences component behavior at runtime. Now, in this second post, we shift focus to another key attribute: Read-Only.

While it may seem straightforward, Read-Only in APEX is packed with flexibility and nuance. From static settings to conditional logic using PL/SQL or SQL expressions, understanding how this attribute works under the hood can help you build cleaner, more secure, and more maintainable applications.

Read Only

Very much like server-side conditions, the Read Only attribute in APEX also supports its own conditional logic. This allows you to control when a component—typically an item or region—should be rendered in a non-editable state, based on dynamic conditions.

Just like with server-side conditions, you can base this on item values, SQL queries, or PL/SQL expressions, giving you fine-grained control over when users can or cannot modify data.

Keep in mind that read-only conditions cascade: if a region is set to read-only, all items within it will also be read-only by default. The following example shows the default look and feel of read-only floating label templates in Universal Theme 24.2, with the read-only condition applied at the form level.

If you want a specific item—say a search field—to always remain editable regardless of the region’s read-only state, simply set that item’s Read Only Condition to “Never.” This effectively overrides the region setting and ensures the item stays editable.

Perhaps more interesting—and more important—is understanding what happens behind the scenes when the read-only attribute is set to true. Let’s break down the generated code to see exactly what’s happening at the item level.

<div class="t-Form-itemWrapper">
    <input 
        type="hidden"
        data-for="P3_JOB"
        value="Wdy9uFm1u3IG9An.....fRZrMefjsTTQevJoFWH7pjGkqpAX7K_OtOufMZHg">
    <input
        id="P3_JOB" 
        name="P3_JOB"
        class="js-accessible-readonly apex-item-text-readonly" 
        aria-readonly="true"
        spellcheck="false" 
        inputmode="none" 
        autocomplete="off" 
        value="CLERK" 
        size="32" />
</div>

Read-Only Attribute in APEX

A typical developer might expect Oracle APEX to use the standard HTML readonly attribute to make an item read-only. However, that’s not how APEX works.

Instead, Oracle APEX simulates read-only behavior using CSS and JavaScript, rather than relying on the native readonly attribute. Why? While we can’t say for certain, it seems APEX opts for a “fake read-only” approach for a few practical reasons:

• The input remains focusable, which benefits screen readers and allows users to copy values.

• Users can’t type into the field—it looks and acts read-only.

• The field's value is submitted with the form, unlike disabled inputs, which are ignored during submission.

This hybrid method gives APEX fine-grained control over the user experience while maintaining accessibility and functionality.

UPDATE: After publishing this post, the Oracle APEX team reached out to share the main reason behind this behavior. It turns out that APEX’s “fake read-only” approach isn’t just a design choice—it’s a workaround for a Chromium bug that causes accessibility issues for keyboard and screen reader users when using the native readonly attribute on text and textarea elements.

By simulating read-only with CSS and JavaScript, APEX avoids these problems while still ensuring values are submitted with the form. According to the team, if the Chromium bug is ever fixed, APEX will revert to using the native readonly attribute.

CSS Classes Used for Read-Only Items

Oracle APEX uses a combination of CSS classes to simulate read-only behavior, rather than relying on the native HTML readonly attribute. Two key classes are involved:

js-accessible-readonly
This class informs APEX’s JavaScript that the input should behave as read-only. Although users can’t modify the field, its value is still submitted with the form. It serves as a functional indicator rather than a visual one.

apex-item-text-readonly
This styling class handles the visual aspect. It makes the input look like a regular text field, but with a grayed-out or non-editable appearance to clearly signal that it’s read-only.

Together, these classes provide consistent behavior and appearance across different components, while maintaining accessibility and proper form submission.

If you're curious about the specific CSS properties applied to read-only items, you can explore them directly. Just open your browser’s developer tools or inspect the core.css file in your APEX installation's static files. Look for any of the following read-only-related classes (e.g., apex-item-autocomplete-readonly, apex-item-text-readonly, etc.) to see how APEX handles different item types in read-only mode.

ARIA Attribute

The aria-readonly attribute is used for accessibility. It tells screen readers and assistive technologies that an input is read-only—even if the standard HTML readonly attribute is not present. This helps maintain a consistent experience for all users.

Inputmode Attribute

As per the MDN Web Docs, the inputmode global attribute is an enumerated attribute that provides a hint about the type of data a user is expected to enter. This helps browsers display a context-appropriate virtual keyboard, particularly on mobile devices.

In the context of read-only fields, inputmode is sometimes set to none to discourage input.

Checksum

Perhaps the most important aspect of APEX's read-only mechanism is the hidden item generated alongside the read-only input. This hidden field stores a checksum value, which is submitted together with the original item.

During page processing, APEX uses this checksum to automatically validate that the value of the read-only item hasn't been tampered with by the user. If the checksum doesn't match, APEX raises a security error—ensuring data integrity for read-only items.

When Inputs Go Read-Only

Apart from the changes at the item attribute level, APEX also generates 'special' form items—such as date pickers, select lists, and popup LOVs—as input elements with their corresponding display values.

These components behave slightly differently when marked as read-only, often being rendered as plain text while still maintaining their functional styling. In all cases, APEX generates the necessary checksums behind the scenes to ensure data integrity and prevent tampering, just as it would for standard items.

Processing Read-Only Items

Last but not least, it’s worth mentioning the processing behavior of read-only forms or pages. When a page or region is marked as read-only, the backend processing remains unchanged. Validations will still run against read-only items just as they would for editable ones, and page processes—including custom PL/SQL processes—will continue to execute as expected.

You might assume that the Automatic Row Processing (DML) process would be skipped if the entire form region is rendered as read-only—but that’s not the case. APEX does not automatically disable processes based on the read-only state of a region or item. It’s up to the developer to implement any conditional logic to skip processing if needed.

That concludes everything I wanted to share about the read-only attribute in Oracle APEX.

Enjoy life!

This first post in the series focuses on standard attributes shared across APEX components. While these attributes aren’t limited to items, understanding them is essential to fully leverage what APEX has to offer. In this post, we take a deep dive into the Server-side Condition attribute.

Server-Side Conditions

As the name suggested, Server-Side Condition attribute controls whether a component is rendered or processed, depending on the context. It applies to almost anything in APEX — regions, items, buttons, dynamic actions, validations, processes — and even to shared components like navigation menu entries or breadcrumbs.

When we say a condition controls rendering, it means that based on the condition you define, APEX decides whether to generate the corresponding HTML or JavaScript code for that component.
If the condition is not met, the code simply won’t exist in the HTTP response sent to the client — it’s as if the component doesn’t exist on that page load.

When it comes to processes, validations, or computations, the condition determines whether that PL/SQL block is executed on the server.

Types

Oracle APEX offers a wide variety of predefined condition types, which can be broadly grouped into:

• SQL-based checks (like “Rows returned”)

• PL/SQL or SQL Expressions or function bodies

• Request & item value comparisons

• User or session context checks (like language, authentication, )

• Never

Tip: Different components offer different types of conditions, and each condition type may require specific attributes. Be curious—explore the help texts and list of values to discover all the options available.

These conditions are essentially declarative (low-code) constructs that you can easily configure. Behind the scenes, however, every one of these conditions ultimately translates into a piece of PL/SQL code.

For example, when you use the Request = Value type, you simply specify the value to compare against.

Most likely, the APEX engine will then translate this into something like the following PL/SQL check behind the scenes:

:REQUEST = 'LOW_CODE'

As a personal preference—and given that PL/SQL is the engine behind the scenes in Oracle APEX—I prioritize PL/SQL expressions over SQL for conditions. When you write a condition using SQL, APEX translates it into dynamic SQL, which introduces a context switch that can impact performance over time. My general recommendation: avoid using SQL in conditions whenever possible. Stick with PL/SQL and you’ll be on the safe side 😄

A common example I’ve encountered in practice:

Instead, I prefer to use a PL/SQL Expression with the following code:

to_date(:P1_FROM_DATE, :APP_NLS_DATE_FORMAT ) < sysdate

Server-Side Conditions in the APEX Dictionary Views

To fully leverage the potential of the Server-side Condition attribute, you can rely on APEX data dictionary views to dynamically build conditions based on your application’s metadata. For example, if you want to implement an alert region on Page 0, you could do something like this:

You might not want that region to render in modal dialogs. In that case, you can easily target only normal pages by using a Rows Returned condition like this:

select 1
from apex_application_pages
 where application_id = :app_id
 and page_id = :app_page_id
 and page_mode = 'Normal';

Oracle APEX Dictionary Views can also help you identify the server-side conditions used throughout your applications.

By querying these views, you can see where and how different conditions are applied, which often reveals opportunities for code improvements or better reuse. For example, you can select condition-related columns from multiple views like this to gain valuable insights:

select 
    application_id, 
    page_id, 
    region_name, 
    condition_type,
    condition_type_code,
    condition_expression1,
    condition_expression2
  from apex_application_page_regions
 where application_id = :app_id

This would result in something like the following:

Never say never

it’s worth mentioning that the once-popular “Never” condition has largely been replaced by a more flexible and easier-to-use option: setting the Build Option to “Commented Out” (found under the component’s configuration attributes).

This approach is especially handy during debugging, as it lets you temporarily disable the rendering of a component to help isolate problems. However, be aware of a drawback: when you change a condition to Never, any existing condition gets removed, and there’s a good chance you might forget what it was before—so take note of it somewhere first!

Tip: Unlike server-side conditions, which are evaluated independently for each component and not cached, authorization schemes support configurable caching strategies such as Once per session or Once per page view. This makes them more efficient when applying the same logic across multiple components—plus easier to maintain.

Enjoy life!

Sounds like a great opportunity to share a quick post to help others who faced the same issue—or perhaps didn’t even realize there was one!

In this example, we'll use some of the bundled helpers from the Oracle APEX Universal Theme to solve common UI challenges.

The Problem

They say a picture is worth a thousand words, so here’s a great example of a common problem I face—and maybe one you’ll notice from now on too.

1# Automatic Column Span

My issue in this case is related to the automatic region span. By default, APEX evenly distributes regions within the same row unless specified otherwise. If you want to change this—especially if you're new to the low-code world—you should know that you can control both the column span and starting position declaratively from the region Layout attributes.

As you might know, the Universal Theme implements a 12-column grid system. You can learn more about it here. In my case, it would be enough to set the Instruction regions to use 4 out of the 12 columns, allowing the Charts to automatically span across the remaining 8 columns.

The result might already look a bit more attractive on a desktop:

But unfortunately, that wouldn’t be the case for a mobile or even a tablet display:

To solve this issue, there isn't a "no-code" solution, but a low-code approach is available instead.

By manually setting the breakpoints for our regions using native CSS classes, we can control when the region spans change. In this case, adding the following CSS classes to the Column CSS attribute for the Chart and Instruction regions will improve the situation:

col-xxs-12 col-xs-12 col-sm-6

The col-AAA-NN classes define how many columns a specific element will span on different screen sizes. When setting multiple elements on the same row, make sure that the total column span for each screen size always adds up to 12.

For example, if you have two regions and one is set to col-xxs-12 col-xs-6 col-sm-4 col-md-3 col-lg-2, the second region will need to have classes that complete the 12 columns. In this case, it should be set to: col-xxs-12 col-xs-6 col-sm-8 col-md-9 col-lg-10.

2# Growing containers

You might notice in our example that the instruction boxes next to the charts don’t match the charts' size. While they might align on certain screen sizes, APEX doesn’t guarantee this by default. Fortunately, there’s a simple way to fix it using flex helper classes, which I have already explained here.

The result after applying the u-flex-grow-1 class:

#3 Fonts

A real added value, at least for me, are the new typography classes. You can read more about them in the official Universal Theme documentation here.

As a quick demo, I just added these classes: u-text-body-md u-text-lighter u-hyphen in the CSS attribute of the region, alongside the already existing u-flex-grow-1 (see the previous topic).

The result would look something like this:

#4 Collapse Order

Last but not least, there's the problem that bothers me the most. In the case of an alternate layout, where there is an intercalation of text and images or charts and text, like in this example, the collapse order becomes crucial. Typically, on a mobile device, there will be two images (or charts) displayed next to each other, which makes the order of their collapse important.

Take this example and notice that the two instruction regions are now stacked, one on top of the other:

Ugly enough, right? Luckily, in APEX 24.2, a native solution for this has been included that allows us to set the collapse order of the regions using the same principle we use for the column span.

By adding u-order-xxs-2 u-order-xs-2 to the already existing u-flex col-xxs-12 col-xs-12 col-sm-6, we can achieve the final version of our dashboard:

Enjoy Life!

To optimize it, I created a straightforward SQL query that handles this logic directly, ensuring only business days are considered.

I also enhanced the query to include the ability to move both backward and forward in time, all controlled by a single bind variable that defines the offset.

SELECT
    d
FROM
    (
        SELECT
            d,
            ROWNUM rn
        FROM
            (
                SELECT
                    sysdate + ( ( level ) * abs(:p_offset) / :p_offset )         d,
                    to_char(sysdate +(level), 'DY', 'NLS_DATE_LANGUAGE=ENGLISH') AS target_day
                FROM
                    dual
                CONNECT BY
                    level <= abs(:p_offset) * 2
            )
        WHERE
            target_day NOT IN ( 'SAT', 'SUN' )
    )
WHERE
    rn = abs(:p_offset);

In case you want to implement holidays as well, you can rely on a REST API for that:

WITH dy AS (
    SELECT
        sysdate + ( ( level ) * abs(:p_offset) / :p_offset )         d,
        to_char(sysdate +(level), 'DY', 'NLS_DATE_LANGUAGE=ENGLISH') AS target_day
    FROM
        dual
    CONNECT BY
        level <= abs(:p_offset) * 2
), dd AS (
    SELECT
        MIN(d) mind,
        MAX(d) maxd
    FROM
        dy
), h AS (
    SELECT
        TO_DATE(holiday_date, 'yyyy-mm-dd') holiday_date,
        holiday_type
    FROM
        JSON_TABLE ( apex_web_service.make_rest_request(p_url => 'https://date.nager.at/api/v3/PublicHolidays/2024/US', p_http_method => 'GET'
        ), '$[*]'
            COLUMNS (
                holiday_date VARCHAR2 ( 20 ) PATH '$.date',
                holiday_type VARCHAR2 ( 50 ) PATH '$.types[0]'
            )
        )
    WHERE
        holiday_type = 'Public'
), hh AS (
    SELECT
        holiday_date
    FROM
             h
        CROSS JOIN dd
    WHERE
        holiday_date BETWEEN mind AND maxd
)
SELECT
    *
FROM
    (
        SELECT
            d,
            ROWNUM rn
        FROM
            (
                SELECT
                    trunc(d) d
                FROM
                    dy
                WHERE
                    target_day NOT IN ( 'SAT', 'SUN' )
                MINUS
                SELECT
                    holiday_date d
                FROM
                    hh
            )
    )
WHERE
    rn = abs(:p_offset);

Enjoy Life!

While the MapLibre APEX implementation offers a robust set of declarative features, there were still some missing functionalities that were crucial for my latest project.

As usual, when a client has a problem, there are two ways to approach it: either I have the solution, or I find one.

In this case, it was the latter.

The problem

In this particular case, the goal was to display multiple markers, representing spatial points, on a map. The key functionality required was to allow users to interact with the map by manually adjusting the position of each marker. This would provide a way for users to fine-tune the location of these spatial points directly on the map interface.

As the markers are moved, the updated coordinates would need to be captured and reflected in real time, with the new positions being automatically saved and updated in a corresponding database table for each record. This feature was essential to ensure data accuracy and flexibility for the user.

Considering a solution

It’s no secret that I’m a fan of solving problems in Oracle APEX in the simplest and most native way possible. While exploring my options for this particular challenge, I quickly realized a few limitations:

• There was no declarative option to create draggable markers within the Maps Region.

• There were no dynamic actions available that could handle or simulate this behavior.

• The component lacked an 'Initialization JavaScript Function' that would suggest room for further customization or flexibility.

• To make matters more challenging, there was little to no information available online about how to address a similar issue.

This left me with no choice but to dive deeper and come up with a custom solution.

Exploring MapLibre documentation

The first thing I needed to do was understand the technology behind the scenes and determine whether the JavaScript library supported this functionality at all.

After diving into the MapLibre documentation, I quickly discovered that draggable markers were indeed a built-in feature. It was as simple as setting the draggable flag to true when creating the markers.

    new maplibregl.Marker({ draggable: true});

You can find two working examples in the official documentation:

• Create a draggable point

• Create a draggable Marker

Exploring the Oracle APEX JavaScript API

The next logical step was to check the Oracle APEX JavaScript API documentation to find a way to influence how APEX creates the points on the map.

As you might have already noticed, there is a mapRegion interface in the API, which, as stated in the documentation, is used to access the properties and methods of the spatialMap API. More information can be found here.

Unfortunately, there is no method or property in the API that would allow me to solve my problem in an obvious way. However, after some time spent reading, I eventually found what I needed.

The getMapObject method

As stated in the documentation, the getMapObject method returns the MapLibre GL JS Map object after initialization.

To me, this reads as, 'If we cannot solve your problems, here is the map; do as you please'—in other words, exactly what I needed.

You might wonder, 'What can you do with this?' Well, in this case, you can take control of the map instance using a Map Initialized Dynamic Action and operate with it using all the features offered by the library itself that are not wrapped in the APEX JavaScript API implementation.

For example, you can fly to a certain location on the map with just the following code:

let map = apex.region("airportMap").getMapObject();
map.flyTo({
    center: [0, 0], 
    zoom: 11, 
    speed: 0.2,
    curve: 1
});

The official documentation can be found here.

The actual solution

Given that there is no native way to influence the creation of markers in APEX, the solution was clear to me: I would need to create my own markers.

Here’s the ingredient list:

• A collection containing at least the ID, latitude, and longitude of the points

• A hidden item computed with a JSON string from the collection to read the points’ data for adding the markers to the map object.

• A native Map Region

• An AJAX Callback Process to update the collection when the drag ends

• A 'Map Initialized' Dynamic Action to load my draggable markers with custom JavaScript

• Optionally, you can include a report on top of the collection.

The collection

Just a collection—nothing too complicated here. In this example, I am using the Sample Airport Data from the Sample Maps APEX application and limit the result set to 5 records for simplicity:

DECLARE
    l_query varchar2(4000);
BEGIN
    l_query := q'!
        select
            ID,
            nvl(
                to_number (
                    JSON_VALUE (geojson_result, '$.coordinates[0]')
                ),0) lat,
            nvl(
                to_number (
                    JSON_VALUE (geojson_result, '$.coordinates[1]')
                ),0) lng, 
            IATA_CODE,
            AIRPORT_TYPE,
            AIRPORT_NAME,
            CITY
        from (
            select a.*, 
                SDO_UTIL.TO_GEOJSON (geometry) AS geojson_result
            FROM EBA_SAMPLE_MAP_AIRPORTS a
            where city = 'ANCHORAGE'
            and rownum < 6
        )!';

    APEX_COLLECTION.CREATE_COLLECTION_FROM_QUERY_B (
        p_collection_name => 'MAP_MARKERS',
        p_truncate_if_exists => 'YES',
        p_query => l_query
     );
END;

The Computation

In order to create markers, you will need information to populate the markers’ attributes. This information will be read in the JavaScript section from a JSON file. In my case, I placed this data in a hidden item and computed it after the collection, using the collection sequence as an ID as it is required for the UPDATE_MEMBER_ATTRIBUTE procedure.

Here’s my SQL query (returning a single value) computation that generates the JSON in a format adapted from the official example and stores it in the hidden item P5_JSON:

SELECT
    JSON_OBJECT (
        'features' VALUE JSON_ARRAYAGG (
            JSON_OBJECT (
                'id' VALUE seq_id,
                'cssClasses' VALUE 'fa fa-2x fa-map-marker u-color-1-text',
                'geometry' VALUE JSON_OBJECT (
                    'type' VALUE 'Point',
                    'coordinates' VALUE JSON_ARRAY (
                       c002, c003
                    )
                )
            )
        )
    ) AS jstr
from apex_collections
where collection_name = 'MAP_MARKERS'

The map region

The map region is, in my case, simply a map region—not too complicated. However, be sure to set a static ID for the map region, in my case, airportMap.

Since at least one layer is mandatory for the region and this layer wasn’t needed for my purposes, I opted to pass a query that retrieves no data from the database to conserve computing resources.

This will render and empty map of the world, but feel free to customize it to fit your needs.

The AJAX callback process

Once again, there’s no magic—just an AJAX Callback process that executes some PL/SQL code to update the collection member with the new coordinates.

APEX_COLLECTION.UPDATE_MEMBER_ATTRIBUTE (
    p_collection_name   => 'MAP_MARKERS',
    p_seq               => apex_application.g_x01,
    p_attr_number              => 2,
    p_attr_value              => apex_application.g_x02
);


APEX_COLLECTION.UPDATE_MEMBER_ATTRIBUTE (
    p_collection_name   => 'MAP_MARKERS',
    p_seq               => apex_application.g_x01,
    p_attr_number              => 3,
    p_attr_value              => apex_application.g_x03
);

Creating Markers: The Actual Magic

The final step involves a block of JavaScript that will be triggered by the Map Initialized component event. I created a Dynamic Action and configured the When section attributes as shown below, ensuring that the correct map region is selected:

Next, create an Execute JavaScript Code True Action with the following code:

// Retrieve the MapLibre map object from the APEX region
let map = apex.region("airportMap").getMapObject();

// Parse the JSON string stored in the hidden item P5_JSON
let geojson = JSON.parse($v("P5_JSON"));

// Function to handle the drag end event of markers
function onDragEnd() {
    // Get the longitude and latitude of the marker after dragging
    const lngLat = this.getLngLat();
    const element = this.getElement(); // Get the marker element

    // Send an AJAX request to update the location in the database
    apex.server.process('UPDATE_LOCATION', {                             
        x01: element.dataset.id, // Marker ID
        x02: lngLat.lng,        // Updated longitude
        x03: lngLat.lat         // Updated latitude
    }, {
        success: function () {             
            // Refresh the collection report on success (Optional)
            apex.region('markerReport').refresh();
            console.log("Location updated in collection");
        },
        dataType: "text" // Specify the response type (plain text)
    });
}

// Loop through each feature in the GeoJSON data to create markers
geojson.features.forEach(marker => {
    // Create a new div element for the marker
    const el = document.createElement("div");
    el.className = "maplibregl-marker maplibregl-marker-anchor-center"; // Set marker classes
    el.dataset.id = marker.id; // Set the marker ID as a data attribute

    // Create a span element for additional marker styling
    const chd = document.createElement("span");
    chd.className = marker.cssClasses; // Set CSS classes from the marker data
    el.appendChild(chd); // Append the span to the marker element

    // Create a new draggable marker and add it to the map
    new maplibregl.Marker({ draggable: true, element: el })
        .setLngLat(marker.geometry.coordinates) // Set the initial position of the marker
        .addTo(map) // Add the marker to the map
        .on("dragend", onDragEnd); // Attach the drag end event handler
});

// Center the map on the last marker's coordinates
if (geojson.features.length > 0) {
    const lastCoordinates = geojson.features[geojson.features.length - 1].geometry.coordinates; // Get last marker coordinates
    map.flyTo({ center: lastCoordinates, zoom: 11 }); // Fly to the last marker's position
}

The result

As you can see, even if APEX doesn't support certain features declaratively, it provides the tools necessary to solve your problems creatively. With a bit of ingenuity, the sky is the limit!

Enjoy Life!

The Challenge

The requirement was pretty straightforward: we needed to display a block of text, but limit the number of characters or lines visible, with a button that allows the user to toggle between viewing the full text and collapsing it back to the limited version.

This kind of feature is great for improving user experience on pages where long text descriptions can clutter the interface. It also gives users more control over how much information they want to see at a glance.

The first step towards a solution

Luckily, Oracle APEX's Universal Theme made this much easier than I anticipated. There’s a native CSS class that can help us handle text truncation: The u-lineclamp-N class will limit the displayed lines to the number specified in the class, ranging from 1 to 5.

You can find the official documentation here.

Let's showcase this with a simple example. Imagine a classic report like the following:

As you can see, excessive text can disrupt the user experience. As an alternative, we can limit the number of visible lines in a block of text to two, which can be easily achieved using the following code in an HTML Expression in a report column:

<span class="u-lineclamp-2">#EMP_BIO#</span>

This simple class ensures that only two lines of text are displayed initially, with the rest hidden, regardless of screen size. This is where the added value lies.

The result may be a more compact report that visually simplifies finding the right record in the table:

Now that we have limited the number of lines, we might consider giving the user control over displaying the full text.

Adding Expand/Collapse Functionality

Using a simple piece of JavaScript, we can technically solve the problem by toggling classes in the previously mentioned <span>. In this case, we replace u-lineclamp-2 with a non-existent one, such as no-line-clamp. jQuery offers a solution out of the box; here’s the basic idea:

$("CSS_Selector").toggleClass('u-lineclamp-2 no-line-clamp')

This function will switch the specified classes on the element in the selector, displaying the full text or hiding it again, regardless of screen size.

The simplest way to incorporate this code is once again in the HTML expression of the report column.

<span 
    class="u-lineclamp-2"
    onclick="$(this).toggleClass('u-lineclamp-2 no-line-clamp');">
    #EMP_BIO#
</span>

As you can see, with two simple lines of code, the user experience can increase dramatically.

Now it's up to you to trigger that action from a better position or style the span element to clearly indicate to the user that the text is clickable.

Final Thoughts

This approach leverages the built-in classes of Oracle APEX's Universal Theme, making it both efficient and clean. There's no need to reinvent the wheel or write complex custom CSS—the APEX Team has already done that for you! :)

Enjoy life!

While Oracle APEX offers a native solution with Master-Detail reports, we can agree that it's not the most user-friendly or visually appealing approach.

Recently, I discovered a straightforward method to display nested data inline for a master record. Before diving into the solution using template directives or HTML expressions in report columns, let’s revisit the old, less attractive way of doing this in APEX.

Ugly Result Simple Way

The most basic solution to your problem is to leverage SQL by using the LISTAGG aggregation function. This allows you to concatenate values separated by commas, creating what we might call a 'nested column.'

Here’s a simple example of what can be achieved quickly and easily, though it's not the most visually appealing solution:

with e as (
    select 
        deptno,
        listagg (ename || ' (' || JOB || ')', ', ') emps
    from emp
    group by deptno
)
select 
    dname department, 
    emps employees
from dept d 
join e on e.deptno = d.deptno

If we create a classic report using this query, APEX will deliver a functional report out of the box that will, hopefully, get the job done:

Simple Result Ugly Way

It quickly becomes clear that the result isn't ideal from a user interface perspective, if nothing else. My second attempt to address the issue involved adding some custom HTML tags directly into the query. Keep in mind that, at the time, HTML expressions weren't as widely available as they are today.

Here’s a potentially improved query:

with e as (
    select 
        deptno,
        '<ul>' ||
            listagg ( '<li>' || ename || ' (' || JOB || ') </li>', '') ||
        '</ul>' emps 
    from emp
    group by deptno
)
select 
    dname department, 
    emps employees
from dept d 
join e on e.deptno = d.deptno

This method requires lowering the security settings on the column to avoid escaping special characters. As a result, it's far from a recommended approach, especially in APEX versions that already support template directives. The outcome:

Improved Result Simple Way

With the introduction of HTML Expressions and Template Directives, this problem can now be solved in an elegant way. There's no longer a need to hardcode HTML in queries, which makes them difficult to read and maintain, nor is there a need to disable default security features.

For the example above, the Loop Clause is a perfect fit. We can revert to the query from the first example and simply create the unordered list in the HTML Expression attribute of that column, like this:

   <ul>
        {loop "," TAGS/}
            <li>&APEX$ITEM.</li>
        {endloop/}
    </ul>

Alternatively, using the exact same technique, you can create a table within that column:

<table>
    {loop "," EMPLOYEES/}
        <tr><td>&APEX$ITEM.</td></tr>
    {endloop/}
</table>

The result should be exactly the same as before but achieved in a native and secure way within Oracle APEX.

Improved Result Improved Way

Assuming you're still following along, you'll notice that the user interface isn't ideal in the previous examples.

In each case, I wanted to aggregate two columns (Name and Title) into the details column, but it wasn’t possible to format each value separately.

Here’s the solution I found, still using native APEX functionalities. In this approach, I concatenate the Employee Name and Title, separated by a :. The result can be interpreted as a Key-Value detailed column, formatted like this:

key1:value1,key2:value2,keyN:valueN

Here’s the query:

with e as (
    select 
        deptno,
        listagg (ename || ':' || JOB, ',') emps
    from emp
    group by deptno
)
select 
    dname department, 
    emps employees
from dept d 
join e on e.deptno = d.deptno

Here's the trick: by using a combination of template directives with loops, case and with, we can split the record twice to apply different styling to each piece of information.

<dl>
{loop "," EMPLOYEES/}
    <dt class="padding-sm">
    {loop ":" APEX$ITEM/}
        {case APEX$I/}
            {when 1/}
                &APEX$ITEM.
            {when 2/}
                {with/}
                    LABEL:=TITLE
                    VALUE:=&APEX$ITEM.
                    LABEL_DISPLAY:=N
                    STYLE:=t-Badge--subtle
                    SHAPE:=t-Badge--circle
                {apply THEME$BADGE/}
        {endcase/}
    {endloop/}
    </dt>
{endloop/}
<dl>

The result:

Wow! You might be wondering what just happened. Here’s a quick explanation:

According to the documentation, there are two substitution strings available in the Loop directive:

• APEX$ITEM: Represents the value of the current item in the list.

• APEX$I: Indicates the 1-based index of the current item in the list.

For more information about template directives, you can refer to the documentation here.

What isn’t explicitly mentioned in the documentation is that you can loop again and use the APEX$ITEM substitution in the second loop to re-split the value using a different separator, such as :.

By combining a case directive with the APEX$I substitution, you can differentiate between the "Key" (value at index 1) and the "Value" (value at index 2), allowing you to apply different styling.

In my case, I simply print the ENAME while applying a badge template to the TITLE column using the WITH clause.

Colorful Templating

If you weren’t aware of the APEX$I substitution, here’s another quick use for it. Although the syntax of template directives is quite limited, you can still leverage the Index substitution to apply a color class to each element in a visually appealing way. Note the u-color-&APEX$I. syntax in the STYLE clause.

<dl>
{loop "," EMPLOYEES/}
    <dt class="padding-sm">
        {with/}
            LABEL:=EMPLOYEE
            VALUE:=&APEX$ITEM.
            LABEL_DISPLAY:=N
            STYLE:=t-Badge--subtle u-color-&APEX$I.
            SHAPE:=t-Badge--circle
        {apply THEME$BADGE/}
    </dt>
{endloop/}
<dl>

Here's a simplified example to illustrate the concept:

Enjoy Life!

After some initial research and not finding exactly what I needed, I decided to tackle the problem myself. As I've mentioned before, I prefer to use as many native classes as possible and aim to create sustainable code that remains intact through any theme updates. This approach involves avoiding hardcoded values for sizes, colors, or other CSS properties.

Here is the result.

And here are the steps:

1. Make sure your Card Region has a Static ID. In my example, card-post-it.

2. In your Card Report, set the CSS Classes attribute to one of the color classes from the palette. For this case, use u-color-6.

3. Add the following custom CSS class in Theme Roller:

/* Post-it Notes CSS */
#card-post-it .a-CardView-items {
  --a-cv-shadow: 0 0px 0px 0px rgba(0, 0, 0);
}

#card-post-it .a-CardView {
    border: 2px solid var(--u-color-36);
}

#card-post-it .a-CardView:before {
  content: "";
  position: absolute;
  bottom: -2px;
  right: -2px;       
  border-top: 20px solid var(--u-color-36);
  border-right: 20px solid var(--a-cv-background-color); 
}

To improve the appearance of the notes, follow these steps:

• Remove the Card Shadow: To remove the card shadow, override the --a-cv-shadow variable with 0 0px 0px 0px rgba(0, 0, 0). This change applies only to this report by using the Static ID #card-post-it .a-CardView-items.

• Set the Card Border: Adjust the border of the cards to a darker version of the selected color by using the CSS variable var(--u-color-36). Here's the breakdown of the color palette:

  • u-color-6 is the base color.

  • u-color-21 is a lighter version of the base color.

  • u-color-36 is a darker version of the base color.

• Apply the Folded Effect: For the folded effect on the bottom right corner, use CSS variables to ensure color adjustments don't disrupt the design. In the top section, apply the dark color (--u-color-36), while in the right section, use the --a-cv-background-color. This approach keeps the design consistent with any color changes.

You can learn more about colors in the Universal Themehere.

Enjoy Life.

In this post, I will explore the integration of multiple public authentication providers, which can add flexibility to your application. This allows users to log in using their Google or Microsoft accounts, depending on their preference or existing credentials.

Delegating the authentication process means you won't need to save or handle any user credentials. There's no need for registration or password reset flows—all of this comes out of the box in Oracle APEX using the industry-standard OAuth 2.0.

A few things to consider:

• You’ll need to implement various identity providers to accommodate the majority of your potential users (not covered in this post).

• A landing page will be required for users to choose which provider to use.

• Ensure the "Switch in Session" option is enabled for all authentication schemas.

Multiple Identity Providers

As you might already know, Oracle APEX provides a native and declarative way to integrate with any identity provider that follows the OAuth 2.0 standard. I won’t go into detail on how to set this up, as there's plenty of documentation available on the topic. The process is quite similar for each provider:

1. Register with the provider’s development portal.

2. Create an API key to consume services using your APEX callback URL.

3. Add the credentials to your workspace credentials.

4. Configure the authentication schemas in your application.

5. Make sure the scheme name is simple to avoid complications later on. For example, use GOOGLE for Google or AZURE for Microsoft, rather than something longer like 'Google Identity Provider.

Optionally, if you have multiple applications in the same workspace, you might consider creating a master application to manage authentication—either by sharing the authentication cookie or by subscribing to the schemas in other apps.

By default, one of the configured authentication schemes will be active. When you run your application, users may unexpectedly land on the identity provider’s login page, which can be confusing. For example, they might request access to your application and be redirected to the Google or Microsoft login page without prior notice.

We’ll address this issue in the next section, but first, ensure that the 'Switch in Session' attribute is enabled for all your configured authentication schemes. You can find this option in the Login Processing section of your authentication scheme settings.

This option is critical in the process because, if enabled, it allows the current session's authentication scheme to be changed by passing APEX_AUTHENTICATION=scheme_name in a URL's request parameter. I will explain how this works in the next section.

Provider decision landing page

The first important aspect to consider is the user authentication flow. The logical approach is to present a decision page where users can choose which provider to use. With a button click, users should communicate their choice to APEX.

For my Climbing Club application, I used the following approach:

1. Create a New Public Page: Design a new page with all the information you need for user decisions.

2. Set the New Decision Page as the Home Page: Go to Shared Components > User Interfaces > Attributes > Home URL and set your new decision page as the home page of your application.

   

3. Create a Before Header Branch to redirect users to the Authenticated home page of your application. Under Security, set the Authorization Scheme to Must Not Be Public User. This ensures that users are directed to the page you want them to visit once authenticated, rather than remaining on the decision landing page.

1. On the landing page, create a button for each authentication scheme.

   • Set the button action to Redirect to Page in this Application.

   • Again, for the target page, select the page you want users to visit once they are authenticated.

   • In the 'Request' section, set the Special Request in the format APEX_AUTHENTICATION=<Authentication Scheme Name> as mentioned in the previous section.

With these simple steps, your authentication flow should be clearer for users and flexible enough to allow them to select the identity provider that best fits their needs.

Enjoy Life!

I encountered a recurring issue that always bothered me, but I discovered it's actually easy to fix using native CSS helper classes.

The challenge occurs when trying to set two or more regions within the same row to have equal heights. Here’s a typical example.

Even though hardcoding heights to a fixed value with CSS can often create more problems than it solves, this can be done easily in APEX. You can do it natively and declaratively by using the standard region template—simply by setting the Body Height attribute under Template Options:

Alternatively, you can use native CSS height helpers in APEX, such as hamount, where amount spans from 10 to 800 in increments of 10.

As mentioned earlier, this solution is not optimal for different screen sizes or when you don't control the amount of content in the regions.

After searching for a better approach, I discovered that this issue can be easily resolved in under 30 seconds by using native CSS classes in the Universal Theme.

To achieve this, we need to treat the element as a flex container and its children as flex items. To do this, set the Column CSS Classes attribute to u-flex for all the regions in the same row under the Layout section.

Next, we need to allow the item to grow to fit the available space. There's already a native class available for this, called u-flex-grow-1, which should be set as the CSS Class in the Appearance section. Again, for all the regions in the row.

This will equalize the heights of all the regions based on the tallest one, regardless of screen size.

Enjoy Life!

For instance, imagine users are required to select a shop from a multi-column Popup LOV that displays the shop addresses for easier identification. If users select a shop by name, they might not immediately confirm that their selection is correct.

In such cases, you might use additional outputs in the Popup LOV to populate read-only items, allowing users to validate their choice.

However, simply updating the item values may not be as clear or effective for the user. This is why a small trick to highlight changes in the user interface can be very helpful just with a bit of custom CSS and JavaScript.

Here are the steps:

1. Include the following CSS classes in your custom CSS code in Theme Roller:

@keyframes highlight {    
    50% {background-color: var(--u-color-22);}
    100% { background-color: var(--a-field-input-background-color); }
}
.active {
    background-color: var(--a-field-input-background-color);
    animation-name: highlight;
    animation-duration: 1.5s;
}

2. Add a custom CSS class (e.g., 'ihighlight') to all the items you want to highlight. You can do this in the item properties under Advance > CSS classes

3. 

   Create an On Change Dynamic Action in the item that will trigger the highlight

4. Add this small JavaScript snippet to the True action

$('.ihighlight').removeClass('active').trigger('focus').select();
setTimeout(function () { $('.ihighlight').addClass('active');}, 100);

The result should be something like this:

Enjoy Life!

For all edge cases, the Universal Theme provides a comprehensive list of predefined classes that allow you to adjust the look and feel of your application in a uniquely sustainable way.

Using native classes ensures that after a Universal Theme upgrade, your application will likely remain functional, automatically inheriting any fundamental changes from the Oracle APEX team.

Let me illustrate this with an extreme example: If the APEX team redefines paddings tomorrow, using the native class padding-sm will automatically update the padding from 0.5rem to the new value defined by Oracle's UI/UX team. However, if you hardcode that value in your own CSS, it won't change, potentially causing your application to look inconsistent.

The Problem

Back to the topic, I have recently wanted to create Card-Per-Row template, with a big image on the side. As you can see below, that is possible with the Card Report in the horizontal layout.

Apart from encountering some limitations with these template options, which are off-topic for this post and were confirmed by the Oracle APEX team (see below), I wanted to include a table-type layout inside the Card template to better present the basic information.

The Solution

Having a lot of data inside a card is probably one of those edge cases mentioned above, which is why I attempted to solve the problem using a custom yet native way.

With this simple approach and by using Universal Theme's native CSS helper classes, you can hide the first column with the labels on smaller screens and display an extra row with the same label instead.

<table class="w100p padding-sm">
  <tbody>
    <tr class="hidden-md-up">
      <td>Name</td>
      <td></td>
    </tr>
    <tr>
      <td class="hidden-sm-down">Name</td>
      <td class="u-bold">&ENAME.</td>
    </tr>
    <tr class="hidden-md-up">
      <td>Job</td>
      <td></td>
    </tr>
    <tr>
      <td class="hidden-sm-down">Job</td>
      <td class="u-bold">&JOB.</td>
    </tr>
    <tr class="hidden-md-up">
      <td>Salary</td>
      <td></td>
    </tr>
    <tr>
      <td class="hidden-sm-down">Salary</td>
      <td class="u-bold">&SAL.</td>
    </tr>
    <tr class="hidden-md-up">
      <td>Hire Date</td>
      <td></td>
    </tr>
    <tr>
      <td class="hidden-sm-down">Hire Date</td>
      <td class="u-bold"> &HIREDATE.</td>
    </tr>
  </tbody>
</table>

Check the visibility classes in the documentation here for more info.

The Result

With a bit of extra effort, you can transform your card region horizontal template into a nice-looking info card like this:

Enjoy life!

The benefits are twofold: not only is it incredibly satisfying to assist someone in overcoming their challenges, but it also compels you to delve into solutions for real-life problems, whether you are familiar with them or not. Not to mention that someone else's solution might surpass the one you proposed.

One of my sources of inspiration is the Oracle Forum. Recently, there were two questions on similar topics that I wanted to document here for the record:

1. How to capture a collapsed/expanded event in a collapsible region.

2. How to expand or collapse all records with a single button click.

1. Capturing collapsed and expanded events

If you quickly inspect the code behind the scenes in your browser when expanding or collapsing a collapsible region in Oracle APEX, you will notice that two specific CSS classes are toggled in the region container: is-collapsed and is-expanded .

In my effort to always solve problems natively, declaratively or in a low code way, here was my proposed solution.

Capturing Events - #1 Approach

This low-code approach is based on testing whether the region has certain CSS classes. That check happens when a click on the region icon occurs.

1. Create a Dynamic Action

2. Event: “Click”

3. Selection Type: “jQuery Selector”

4. jQuery Selector: #myRegion .t-Button.t-Button--icon.t-Button--hideShow

5. Add a client-side condition to check if your region now has the is-expanded class.

6. Create your true/false action.

Assuming we have an Alert as the true and false action, this would be the result:

Catching Non Documented Events - #2 approach

Thanks to John Snyders, who in his comment pointed out a better approach to achieving a similar result using two undocumented events.

Here is the original code for the more-code enthusiasts:

// Catch the collaps event
$("#myRegion").on(
    "collapsiblecollapse",() => {
        console.log("collapsed")
});
// Catch the expand event
$("#myRegion").on(
    "collapsibleexpand", () => {
        console.log("expanded")
});

If you are a low-code enthusiast, here is what you can do:

1. Create a Dynamic Action

2. Event: “Custom”

3. Custom Event: collapsiblecollapse or collapsibleexpand

4. Selection Type: “jQuery Selector”

5. jQuery Selector: #myRegion

6. Create your true/false action.

2. Control them all from a sigle button

The second question was about how to control all the collapsible regions from a single control button.

My initial approach was to use a method similar to the previous case, where I caught the click event and triggered an extra click in the second region. While this works, it is not the most elegant or scalable solution.

Again, a better solution comes from the community. Thanks to Karel Ekema for pointing out that there is already a function in APEX to control the collapsible regions.

Unfortunately, I haven't found it in the documentation, but exploring the source code of desktop_all.js provides enough information to get started.

// Expand the collapsible regions provided in the CSS selector.
$('<css_selector>').collapsible('expand');

// Collapse the collapsible regions provided in the CSS selector.
$('<css_selector>').collapsible('collapse');

// Toggle the status of the collapsible regions provided in the CSS selector.
$('<css_selector>').collapsible('toggle');

Using this simple line of code, you can target all collapsible regions at once.

Let's try it:

1. Add a Custom CSS Class:

   • In the "Appearance" section of attributes for all the regions you want to control, add a custom CSS class, e.g., masterAll.

   • 

2. Create a Button:

   • Create a button in your application.

3. Create a Dynamic Action:

   • Event: Click

   • Selection Type: Button

   • Button: Select the button you have just created.

   • 

4. Create a True Action:

   • Action: Execute JavaScript Code

   • Code: $('.masterAll').collapsible('toggle');

   • 

5. Repeat:

   • Repeat the above steps for the Expand/Collapse button.

This results in an easy way of controlling your collapsible regions from a single action button.

Enjoy life!

Here are my findings on customizing fonts in the Oracle APEX Universal Theme.

Changing Font Family

You can achieve the same result using any web fonts, including your own. However, if you're using Google Fonts, just follow these simple steps:

1. Look for the font you want to use - Nunito for instance - and click Get font

   

2. Once you're on the selected font family's landing page, click Get Embed Code.

   

3. From the Embed page, copy the Font URL (highlighted in yellow).

   

4. The final step is to add the Font URL to your application, so APEX can download the font file when needed. The easiest way to do this is by going to Application Builder. While editing your application, navigate to Shared Components > User Interfaces > CSS, and paste the URL into the File URLs section.

   

Now, your application will have the selected font available for use in any of its elements. If you want to apply the font globally across your application, you can set the font properties in Theme Roller. In the Custom CSS section, apply the font at a root level. For example:

:root {
    --a-base-font-family: "Nunito", sans-serif;
    font-size: 18px; // Optional. Default: 16px.
}

A couple of things to highlight from the example:

• The font-family attribute is set at the top of the hierarchy using the :root pseudo-class. Learn more about it here.

• To set the font, override the CSS variable --a-base-font-family instead of setting the attribute directly. Learn more about it here.

• Optionally, you can globally change the font size by simply setting the base font size at the root level as well.

Micromanaging font sizes

If you need precise control over the font sizes of specific components, the Universal Theme in Oracle APEX offers the tools to do so sustainably. The recommended approach is to override the specific CSS variable for your case.

For setting up font sizes, the Universal Theme uses rem as a unit, making all font sizes relative to the root font size. Learn more about it here.

For example, if you set the font size to 18px at the :root level, it will affect all relative sizes across your application, ensuring consistency.

An example of micromanaging font sizes might involve overriding specific components at the top level, as illustrated below:

:root {
    --a-button-font-size: 0.75rem;    
    --a-checkbox-label-font-size: 0.75rem;
    --a-checkbox-label-font-size: 0.875rem;
    --a-checkbox-label-font-size: 1rem;
    --a-chip-font-size: 0.75rem;
    --a-chip-input-font-size: 0.75rem;
    --a-cv-badge-font-size: 0.75rem;
}

If you want to learn more about CSS variables, you can find the full list of them here.

Identifying the Correct CSS Variable

Determining the right CSS class that needs to be overwritten can sometimes be challenging. In this case, you can simply use your browser's web development tools to inspect the rendered code and identify the variable being used.

Here’s an example: Imagine you want to increase the font size of card titles globally. To do this, inspect the card title in your browser by right-clicking on the title — in this case, KING.

In the Inspector section (this example is from Firefox, but it should be similar in other browsers), you should see something like this:

As you can see, the CSS properties of the a-CardView-title class are as follows:

.a-CardView-title {
  color: var(--a-cv-title-text-color);
  font-size: var(--a-cv-title-font-size,16px);
  font-weight: var(--a-cv-title-font-weight,700);
  line-height: var(--a-cv-title-line-height,20px);
  margin: 0;
}

In this example, we're interested in the font size, so the --a-cv-title-font-size variable is the one we need. You can overwrite this at any level, depending on your needs. As mentioned earlier, you can do this at the root level:

:root {
   --a-cv-title-font-size: 1.5rem;
}

And here is the final result:

Enjoy Life!