Search This Blog

Sunday, July 13, 2025

HOW DO I Use CSS for a Spinner

Using a spinner in Oracle APEX enhances user experience by visually indicating that a process is running or data is loading. While APEX provides built-in loading indicators, customizing a spinner with CSS gives you more control over its appearance and behavior, matching your application’s style. In this blog, you will learn how to create and integrate a CSS-based spinner in your Oracle APEX applications to provide clear feedback during asynchronous operations or page processing.How to Use CSS for a Spinner in Oracle APEX

  1. Create the Spinner HTML Element
    Add a container for the spinner in your page where you want it to appear, such as a static region or inside a Dynamic Action. For example:

    <div id="mySpinner" class="spinner" style="display:none;"></div>
    
  2. Define Spinner Styles with CSS
    Add CSS either in the Inline CSS section of your page, in a Cascading Style Sheet file, or within the page’s Inline CSS property. Here is a simple spinner example:

    .spinner {
      border: 8px solid #f3f3f3;
      border-top: 8px solid #3498db;
      border-radius: 50%;
      width: 60px;
      height: 60px;
      animation: spin 1s linear infinite;
      margin: auto;
    }
    
    @keyframes spin {
      0% { transform: rotate(0deg); }
      100% { transform: rotate(360deg); }
    }
    
  3. Show and Hide the Spinner Using JavaScript or Dynamic Actions
    Use JavaScript or Dynamic Actions to toggle the spinner’s visibility during processing. For example:

    // Show spinner
    document.getElementById('mySpinner').style.display = 'block';
    
    // Hide spinner
    document.getElementById('mySpinner').style.display = 'none';
    

    You can attach this code to events such as button clicks, page submit, or Ajax call starts and ends.

  4. Integrate with APEX Processing
    To show the spinner during Ajax requests, use Dynamic Actions on Page Load, Before Submit, or After Refresh to control the spinner’s display, ensuring users get feedback during longer operations.

CSS (Cascading Style Sheets) allows you to control the look and feel of your Oracle APEX applications by customizing colors, fonts, layouts, and responsiveness. Oracle APEX provides several ways to apply CSS, either globally or on specific elements.


Ways to Apply CSS in Oracle APEX

1. Inline CSS (Element-Level Styling)

Inline CSS is applied directly to an HTML element using the style attribute.

Example:

To change the color of a button:

<button style="background-color: red; color: white;">Click Me</button>

Use Case: Quick styling for a specific element without affecting others.


2. Page-Level CSS (Inside Page Attributes)

You can apply CSS to a single page by adding styles inside the Inline CSS section of a page.

Steps:

  1. Go to Page Designer

  2. Under Page Attributes, find the CSS section

  3. Add your CSS in Inline CSS

Example:

To change the font size of all headings on a page:

h1, h2, h3 {

    font-size: 20px;

    color: blue;

}

Use Case: Customizing the style of elements on a single page.


3. Theme-Level CSS (Global Styling for the Whole Application)

To apply styles across your entire APEX application, you can add CSS inside the Theme Roller or in Shared Components > CSS Files.

Option 1: Using Theme Roller

  1. Open Shared Components

  2. Go to Theme Roller

  3. Customize colors, fonts, and styles

  4. Click Save as Style to apply the changes

Option 2: Uploading a CSS File

  1. Navigate to Shared Components > Static Application Files

  2. Click Upload File and upload your .css file

  3. Reference the CSS file in your Page Attributes inside the CSS File URLs section: 

#APP_IMAGES#custom-styles.css

  1. Alternatively, reference the file in Page Header > HTML

<link rel="stylesheet" type="text/css" href="#APP_IMAGES#custom-styles.css">

Use Case: Making global design changes to the entire application.


4. Applying CSS to Specific APEX Elements

You can target APEX elements using CSS classes and IDs.

Common APEX CSS Classes:

  • t-Button → Styles APEX buttons

  • t-Form-input → Styles text fields and inputs

  • t-Region → Styles report regions

  • apex-item-text → Styles input fields

Example: Styling buttons with a custom color

.t-Button {

    background-color: #0073e6;

    color: white;

    border-radius: 5px;

}


5. Using Dynamic CSS with JavaScript

You can dynamically apply CSS styles using JavaScript.

Example: Change the background color of a button on click

document.getElementById("myButton").style.backgroundColor = "green";

Use Case: Applying real-time CSS changes based on user actions.

Using CSS in Oracle APEX enhances the visual appeal and usability of your applications. You can apply CSS at the element level, page level, or application level using Theme Roller or custom stylesheets. Additionally, JavaScript can be used to apply CSS dynamically.

Adding a Spinner via CSS to an Oracle APEX Page

A spinner (or loading indicator) helps inform users that a process is running in the background. You can add a spinner to your Oracle APEX application using CSS and JavaScript.


Method: Using CSS Only

You can create a simple spinner using pure CSS and display it when needed.

Steps to Add a CSS Spinner

  1. Add CSS for the Spinner

    • Navigate to Page Designer

    • Select your page

    • Under Page Attributes, go to Inline CSS

    • Add the following CSS:

/* Spinner Container */

.spinner-overlay {

    display: none; /* Hidden by default */

    position: fixed;

    top: 0;

    left: 0;

    width: 100%;

    height: 100%;

    background: rgba(0, 0, 0, 0.5);

    z-index: 9999;

}


/* The Spinner Animation */

.spinner {

    position: absolute;

    top: 50%;

    left: 50%;

    transform: translate(-50%, -50%);

    width: 50px;

    height: 50px;

    border: 6px solid #f3f3f3;

    border-top: 6px solid #3498db;

    border-radius: 50%;

    animation: spin 1s linear infinite;

}


/* Spinner Animation */

@keyframes spin {

    0% { transform: translate(-50%, -50%) rotate(0deg); }

    100% { transform: translate(-50%, -50%) rotate(360deg); }

}

  1. Add the Spinner to the Page

    • Navigate to Page Designer

    • Go to Regions

    • Add a new Static Content region

    • Set Static ID to spinnerContainer

    • Add the following HTML inside the Region Source:

<div class="spinner-overlay" id="spinnerContainer">

    <div class="spinner"></div>

</div>


Best Practices for Using CSS Spinners in APEX

  • Keep spinners unobtrusive and sized appropriately for the context.

  • Use colors that match your application’s theme for a consistent look.

  • Place spinners near the content or button triggering the action for clarity.

  • Avoid blocking the entire page unless necessary; partial loading indicators improve usability.

  • Test spinner visibility on different devices and browsers.

  • Combine spinner display with disabling UI elements to prevent duplicate actions.

 Oracle APEX Documentation Links

Conclusion

Using CSS to create a spinner in Oracle APEX is a simple yet effective way to improve user experience by visually signaling ongoing processes. With a few lines of CSS and JavaScript, you can customize the spinner’s appearance and behavior to fit your application’s design and needs. Proper use of spinners keeps users informed, reduces confusion, and adds polish to your APEX applications.

Maintaining a Naming Convention

Maintaining a consistent naming convention in Oracle APEX is crucial for developing scalable, maintainable, and understandable applications. Clear and standardized names for pages, regions, items, buttons, and processes help developers quickly identify components, reduce confusion, and streamline collaboration within teams. By establishing and following a naming convention early in your project, you promote cleaner code, easier debugging, and smoother hand-offs between developers. This blog explains how to create and maintain effective naming conventions in Oracle APEX.

How to Maintain a Naming Convention in Oracle APEX

  1. Define Naming Standards for Components
    Decide on prefixes, suffixes, and formats for all APEX objects. For example:

    • Pages: P<number>_ prefix (e.g., P10_ORDERS)

    • Items: use type and purpose (e.g., P10_DATE_FROM, P10_CUSTOMER_ID)

    • Buttons: prefix with BTN_ (e.g., BTN_SAVE)

    • Regions: prefix with RGN_ (e.g., RGN_SALES_CHART)

    • Processes and Dynamic Actions: use descriptive names with a suffix indicating type (e.g., PRC_SAVE_ORDER, DA_VALIDATE_EMAIL)

  2. Use Descriptive and Consistent Names
    Avoid generic names like ITEM1 or BUTTON2. Use names that describe the purpose or content clearly.

  3. Include Object Types and Context
    Incorporate the type of object and the page or module it belongs to, making it easier to locate and understand its function.

  4. Document Your Convention
    Create a shared document or wiki page detailing naming rules and examples. This helps onboard new developers and enforces consistency.

  5. Apply Naming Conventions Early and Enforce Them
    Start using the conventions from the beginning of development and review code periodically to ensure compliance.

Best Practices for Naming Conventions

  • Keep names concise but meaningful.

  • Use uppercase letters with underscores for readability (e.g., P10_CUSTOMER_NAME).

  • Avoid reserved words or special characters that may cause conflicts.

  • Be consistent across all applications and teams to reduce confusion.

  • Use version control to monitor changes and maintain naming discipline.

 To avoid confusion, use a consistent naming pattern:

  • For Dev Work: AppName_DEV, AppName_WorkingCopy

  • For Feature Testing: AppName_NewFeature

  • For UAT Testing: AppName_UAT

  • For Performance Testing: AppName_PerfTest

Example:

Copy Type

Example Name

Main App

CustomerPortal

Dev Copy

CustomerPortal_DEV

UAT Copy

CustomerPortal_UAT

Feature Copy

CustomerPortal_NewFeature

 Manage Working Copy Data

A working copy does not automatically include production data. To work with realistic data:

  • Use a separate schema with sample/test data.

  • Clone production data into a test environment. 

CREATE TABLE customers_copy AS SELECT * FROM customers;

Use Oracle APEX REST Synchronization to pull fresh data.

 Keeping Track of Changes

Since working copies are not automatically synced with the main application:

  • Document all changes in a shared space (e.g., Notion, Confluence, or a text file).

  • Use version control (Git, SVN) to track exported .sql files.

Enable APEX Application Feedback for team reviews.

 Testing Changes Before Merging

Before merging a working copy:

  1. Run comprehensive tests

    • Functional testing (buttons, reports, forms).

    • Performance testing (APEX Debug Mode).

    • Security testing (Authentication & Session State protection).

  2. Validate changes in different screen sizes (Responsive Design).

  3. Check for JavaScript/PLSQL errors in APEX Debug Console.

 

Merging a Working Copy Back into the Main Application

Since working copies are separate, changes must be manually applied to the main app.

How to Merge a Working Copy into Production

  1. Compare pages/components between the working copy and the live application.

  2. Export required pages from the working copy: 

    • App Builder > Export/Import > Export Pages

  3. Import them into the main application.

  4. Deploy in a Staging/UAT Environment for final testing.

  5. Release to production during off-peak hours.


Deleting Unused Working Copies

Once changes are merged, delete old working copies to keep the environment clean:

BEGIN

    APEX_APPLICATION.DELETE_APPLICATION (p_application_id => 200);

END;

Alternatively, archive them in GitHub or a backup folder.


Final Thoughts: Best Practices Summary

  • Use working copies for major changes, not small fixes.

  • Follow a clear naming convention.

  • Use test data instead of modifying production data.

  • Track changes and use version control.

  • Thoroughly test before merging into the main application.

  • Delete old working copies after merging.

Oracle APEX Documentation Links

Conclusion

Maintaining a consistent naming convention in Oracle APEX is a foundational practice that enhances code clarity, maintainability, and teamwork. By establishing clear rules and applying them consistently throughout your application, you reduce errors and simplify development processes. Whether working solo or in teams, adopting a naming convention early on ensures your APEX applications remain organized and easier to support as they grow in complexity.

HOW DO I Use Working Copies for Safe Development in ORACLE APEX

Using working copies for safe development in Oracle APEX helps developers isolate changes, test new features, and avoid disrupting production applications. A working copy is essentially a separate instance or version of your application where you can freely experiment without affecting live users. This approach promotes safer development cycles by enabling developers to develop, debug, and validate enhancements before merging changes back into the main application. In this blog, we explore how to create and manage working copies in Oracle APEX for secure, efficient development.How to Use Working Copies in Oracle APEX

  1. Export Your Current Application
    Begin by exporting the current stable version of your application as a SQL script using the APEX export feature or the APEXExport command-line tool.

  2. Create a New Workspace or Schema for Development
    Set up a dedicated workspace or schema that mimics the production environment. This isolated environment serves as your sandbox for development.

  3. Import the Exported Application as a Working Copy
    Use the import feature in Oracle APEX to load the exported SQL file into your development workspace, creating a working copy of the app.

  4. Develop and Test Independently
    Make your changes, test new features, and fix bugs within this working copy without impacting production.

  5. Version Control Your Working Copy
    Export the working copy periodically and commit changes to version control to track your development progress.

  6. Merge Changes Back to Production
    Once development and testing are complete, export the updated working copy and import it into the production workspace, or apply necessary updates carefully.

Best Practices for Working Copies

  • Maintain separate environments for development, testing, and production to prevent accidental data or logic corruption.

  • Keep your working copies in sync with production by regularly exporting and importing updates.

  • Use version control to manage working copy exports and document changes.

  • Automate backups of both production and working copies before significant changes.

  • Communicate clearly with your team about which version is under development to avoid conflicts.

 Instead of modifying the production app directly:

  1. Go to Utilities > Application Copy.

  2. Create a working copy.

  3. Test changes in the copy before merging them into the main app.


Key Backup Best Practices

  • Export Application & Workspace Regularly

  • Backup the Database (Data Pump & RMAN)

  • Store Backups in Multiple Secure Locations

  • Use Flashback & Undo for Quick Recovery

  • Test Restores Periodically

  • Leverage Version Control (Git, SVN)

  • Use Working Copies for Development Safety

In Oracle APEX, working copies allow developers to safely test and experiment with changes before applying them to the live application. Using working copies properly can help prevent issues in production, facilitate collaboration, and improve overall development workflows.

Understand When to Use a Working Copy

 Use a Working Copy When:

  • Making significant UI/logic changes.

  • Refactoring page structures, processes, or PL/SQL code.

  • Testing new features before deployment.

  • Preparing an application for an APEX upgrade.

  • Collaborating with a team while keeping a stable version.

  • When performing upgrades or migrations.

  • When making major changes to an application.


Do NOT Use a Working Copy When:

  • Performing minor text or style changes (use Live Edit or Developer Toolbar instead).

  • Debugging small issues in development mode.

  • Managing multiple environments (use version control or multiple APEX instances instead).

 Creating a Working Copy of an Application

  1. Go to App Builder and find the application you want to duplicate.

  2. Click on Utilities > Application Copy.

  3. Choose Copy Application and enter a new name (e.g., "MyApp_Test").

  4. Select the components you want to include: 

    • Pages

    • Application Definition (Pages, Shared Components) 

    • Authentication & Authorization

    • Shared Components

    • Data Model

  5. Click Create Application.

This will create a separate copy of the application that you can modify without affecting the original.

 

 Merge Changes from a Working Copy

Once you're satisfied with the changes in the working copy:

  1. Manually track the changes made in the copy.

  2. Apply them to the original application by updating pages, components, or SQL scripts.

If needed, export the working copy and import it as a new version.

 

Oracle APEX Documentation Links

Conclusion

Using working copies in Oracle APEX enables safe, structured development by separating experimental changes from production environments. This practice minimizes risk, facilitates testing, and improves collaboration among developers. By exporting, importing, and managing application versions carefully, and leveraging multiple workspaces, you create a development process that is both robust and flexible—ensuring your applications evolve smoothly without compromising reliability.

 

HOW DO I Track Application Changes Using Version Control in ORACLE APEX

Tracking application changes using version control is essential for managing Oracle APEX development effectively. Version control allows teams to collaborate, maintain a history of modifications, and quickly revert to previous versions if needed. Since Oracle APEX applications are primarily metadata stored in the database, the best practice is to export your application as SQL scripts and manage those scripts using standard version control systems like Git. This blog explains how to set up version control for your APEX apps, including exporting, committing, and tracking changes over time.How to Track Application Changes Using Version Control in Oracle APEX

  1. Export Your Application to SQL Script
    Use the APEX export feature via the web interface or the APEXExport command-line tool to create a SQL file representing your application. This file contains all pages, components, and shared objects.

  2. Store Exported Files in a Version Control Repository
    Create a repository in systems like Git, Subversion, or Mercurial. Commit your exported SQL files to the repository with clear commit messages describing changes.

  3. Develop a Versioning Workflow

    • Export after each significant change or at scheduled intervals.

    • Commit frequently to capture incremental development progress.

    • Use branching strategies for feature development, bug fixes, or releases.

  4. Automate Export and Commit (Optional)
    Incorporate export commands in build pipelines or scripts to automate application exports. Combine with Git commands to automatically commit changes, ensuring no updates are missed.

  5. Use Diff Tools to Compare Versions
    Since exports are text-based SQL scripts, standard diff tools can highlight changes between versions, helping identify what was added, modified, or removed.

  6. Import and Test Changes in Development Workspaces
    Use version-controlled export scripts to import applications into development or test environments, ensuring consistency and controlled deployment.

Best Practices for Version Control with APEX Applications

  • Include supporting objects (tables, packages) in your exports for full application capture.

  • Use descriptive commit messages and tags to mark releases or milestones.

  • Keep export files organized in folders by application or project.

  • Avoid manual edits directly in the database without exporting and committing changes.

  • Regularly merge and resolve conflicts in team environments.

  • Document your version control process to maintain team consistency.

Oracle APEX Documentation Links

 Best Practice: Use Git or SVN for Change Management

Instead of relying only on APEX exports, store application .sql files in Git:

  1. Export APEX application: 

SELECT APEX_EXPORT.GET_APPLICATION(100) FROM DUAL;

  1. Push to a Git repository: 

git add app_100_backup_20240310.sql

git commit -m "Backup of App 100 on March 10, 2024"

git push origin main



Conclusion

Implementing version control for Oracle APEX applications is a best practice that enhances collaboration, traceability, and reliability in your development process. By exporting applications as SQL scripts and managing them with systems like Git, you gain clear insight into your app’s evolution and maintain control over changes. Whether working solo or in teams, version control enables safer deployments and smoother rollbacks—ensuring your Oracle APEX projects stay organized and maintainable over time.

UI Defaults

 In Oracle APEX, User Interface (UI) Defaults are a set of metadata-driven, table- and column-scoped attributes that APEX consults when it g...