Search for a command to run...
Experienced Business Analyst with a demonstrated history of working in the airlines/aviation industry. Strong research professional with a engineer focused and a strong technical background. Skilled in SQL/PLSQL, Linux System Administration. A proud Oracle APEX Consultant.
No comments yet. Be the first to comment.
Audit Information 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 modi...
In this fifth post of The Standard Component Attributes Anatomy series, I’m focusing on the Configuration attribute—better known as Build Options. Since Build Options are managed in Shared Components, we’ll take a quick look at that area as well. Con...
Comments 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 ...
In this fourth post of The Standard Component Attributes Anatomy Series, we’re diving deep into the Help standard attribute. Although often overlooked, the Help attribute plays an important role in improving the user experience by providing clear, co...
In this third post of The Standard Component Attributes Anatomy Series, I’m tackling the Security attribute. Since the Security section includes references to Authorization Schemes from Shared Components, we’ll briefly touch on that as well. And beca...
Preparing for a presentation on APEX items, I’m starting a new series of blog posts exploring the basic capabilities of APEX. The goal is to gain a deeper understanding of how things work behind the scenes and how we can make the most of them.
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.
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.
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
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:
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!