Requirements
The table below describes the requirements that were used to define the plug-in scope. The Native APEX validation and Client-Side Validation Pro columns compare the requirement against native validation provided by Oracle APEX and the capability to fulfill the requirement by the plug-in.
| Requirement | Description | Native APEX Validation | Client-Side Validation Pro | |
|---|---|---|---|---|
| 1 | The plug-in should execute validations on the client-side without an AJAX call. | Usually, client-side validation is done by writing custom javascript functions to validate. The plug-in should execute native Oracle APEX validations without any extra effort from a developer. Purpose: Execute defined APEX validations on the client-side using JavaScript without defining any JavaScript code. |  Oracle APEX validations are always executed on the server-side. |  The plug-in can evaluate natively defined validations using JavaScript based on APEX validation definitions. |
| 2 | The plug-in should allow evaluating validation conditions on the client-side without an AJAX call. | Usually, client-side validation is done by writing custom javascript functions to validate. The plug-in should evaluate native Oracle APEX validation conditions without any extra effort from a developer. Purpose: Evaluate defined APEX validations on the client-side (using JavaScript) condition before executing a validation. | Oracle APEX validations are always executed on the server-side. | The plug-in evaluates natively defined validation conditions using JavaScript based on APEX validation definitions. |
| 3 | The plug-in should be able to execute interactive grid column validations. | Purpose: Support interactive grid column validation. | Native feature | The plug-in supports validating interactive grid columns. |
| 4 | The plug-in should execute all validations server-side using an AJAX call. | The end-user can turn off the JavaScript in their browser settings which is the reason that all validations that can be executed on the client-side should be rechecked on the server-side. Purpose: Prevent end-users from disabling validation using JavaScript. | Oracle APEX validations are always executed on the server-side. | The plug-in always evaluates defined validations on the server-side. |
| 5 | The plug-in should be able to execute items validations on an event triggered on the specified region. | Purpose: Reduce the effort required to validate all items in the specified region. Instead of specifying item(s) specify the region. | Oracle APEX validation can be restricted to a given request (When Button Pressed) which is associated with an APEX button. | When the plug-in affected elements are set to Region, the plug-in will validate all items embedded in the specified region. |
| 6 | The plug-in should be able to validate a given item(s). | Purpose: Give the possibility to specify which items should be validated using the plug-in. | Oracle APEX validation can be restricted to a given request (When Button Pressed) which is associated with an APEX button. | When the plug-in affected elements are set to Item(s), the plug-in will validate all specified items in one execution. |
| 7 | The plug-in should be able to execute items validations on a custom event triggered on the document (DOM tree node) | Purpose: Give the possibility to bind the plug-in validation from global page 0. | Native Oracle APEX validation can be performed only after the page is submitted. | The plug-in supports triggering elements defined as a JavaScript Expression. |
| 8 | The plug-in should be able to execute column validations (for currently edited row) on an event triggered by an interactive grid. | Purpose: Reduce the amount of effort required to bind the plug-in with all interactive grid columns. | Native Oracle APEX validation is done after the interactive grid save action is triggered. | The plug-in supports triggering elements defined as Region (interactive grid). |
| 9 | The plug-in should be able to execute columns validations (for currently edited row) on an event triggered by an interactive grid column. | Purpose: Give more control to a developer as to which columns are validated under the specified conditions. | Native Oracle APEX validation is done after the interactive grid save action is triggered. | The plug-in supports triggering elements defined as Column(s). |
| 10 | The plug-in should execute validations in a defined sequence order. | Purpose: Mimic the native validation process. | Native Oracle APEX validation is done in order of validation sequence. | The plug-in executes validation in the defined validation sequence. |
| 11 | The plug-in should expose validation events. | Purpose: Allow developers to control and enhance the validation process. Using the plug-in events it is possible to visualize the validation process, validation results, and build custom validation flows. | Native Oracle APEX validation doesn’t trigger events. When validation is successful the page is reloaded. When validation fails the page is not reloaded and validation errors are shown. | The plug-in fires different events at each validation step. |
| 12 | The plug-in should allow executing validation after a button is clicked. | Purpose: Mimic native validation behavior. | Native Oracle APEX validation is always performed after the button submitting the page is clicked. | The plug-in validation can be triggered on a button click event which can be combined with the plug-in attributes to create more user-friendly validation. |
| 13 | The plug-in should allow item/column validation on the item/column event. | Purpose: Get validation results right after the user inputs data into the item/column. | Native Oracle APEX validation can be performed only after the page is submitted. | The plug-in validation can be triggered on the item/column events supported by Oracle APEX dynamic actions. For example Change, Key release, and so on. |
| 14 | The plug-in should render validation errors using the Oracle APEX JavaScript API. | Purpose: Mimic native validation behavior. | Native Oracle APEX validation renders validation results using the apex.message API. | Validation errors are shown using the Oracle APEX apex.message API. |
| 15 | The plug-in should display validation errors in positions supported by APEX. | Validation errors can be shown in 4 different positions. Purpose: Mimic native validation behavior. | Native Oracle APEX validation behavior | The plug-in supports 3 positions excluding the On Error Page position. |
| 16 | The plug-in should allow an overriding validation error display location. | Purpose: Give the possibility to show validation errors in different positions depending on triggering events. For example, show validation errors inline with the field when the triggering event is set to Change and show validation errors Inline with Field and Notifications when the specified button is clicked. | Native Oracle APEX validation result positions cannot be changed at run-time. | The plug-in allows overriding the validation position from the perspective of dynamic action implementation. Even though the APEX validation result position is defined to be shown in a particular position, the plug-in can override it. |
| 17 | The plug-in should support HTML5 validations. | The native Oracle APEX validation process includes HTML5 validations. Purpose: Mimic native validation behavior. | Native feature | The plug-in mimics the native approach and HTML5 validations are evaluated. |
| 18 | The plug-in should support translations for HTML5 validations. | HTML5 validation messages are based on end-user browser preferences, which means support the language currently selected by end-user. Purpose: Make translating HTML5 validations easy and maintainable. | Native Oracle APEX HTML5 validations can’t be translated using the native approach. | The plug-in supports HTML5 validation translations using native APEX text messages. |
| 19 | The plug-in should support translations for native validations | Validations are translated using the built-in Globalization feature. Purpose: Mimic the native feature. | Oracle APEX validations are translated using a Shadow Application. | The plug-in supports a Shadow Application. |
| 20 | The plug-in should evaluate the validation authorization scheme before execution. | The Oracle APEX validation process includes evaluation of the authorization scheme assigned to the validation. Purpose: Mimic the native feature. | Native feature | The plug-in mimics the native validation process and evaluates authorization schemes before executing a validation. |
| 21 | The plug-in should evaluate the validation conditions before executing the validation. | Oracle APEX validation process includes the evaluation of defined validation conditions. Purpose: Mimic the native validation behavior. | Native feature | The plug-in mimics the native validation process and evaluates validation conditions before executing a validation. |
| 22 | The plug-in should be able to execute validations with the When Button Pressed attribute defined. | Purpose: Mimic the native validation behavior. | Native feature | The plug-in evaluates validations that have the When Button Pressed attribute set using the plug-in Request attribute. |
| 23 | The plug-in should support the debounce mechanism for events such as Key Down, Key Release, and Key Press for APEX items. | The plug-in debounce mechanism can be applied to APEX items. It is planned to support interactive grid columns in the future. Purpose: Prevent duplicated validations for keyboard events. | Native Oracle APEX evaluates validations only after a page is submitted. | Plug-in feature |
| 24 | The plug-in should expose configurable callbacks on validation results. | Purpose: Allow the possibility to create application flow based on validation results. | Native feature | The plug-in allows creating JavaScript callbacks on validation results. |
| 25 | The plug-in should allow its execution to be debugged. | The plug-in validation process can be inspected using the Oracle APEX debug feature. Purpose: Mimic the native validation debug. | Native Oracle APEX validation can be inspected in debug mode. | The plug-in supports debug mode and logs the plug-in validation process. |
| 26 | The plug-in should combine HTML5, client-side, and server-side validation together | All validations combined together. | Native Oracle APEX doesn’t support evaluating defined APEX validation on the client-side | Plug-in feature |
| 27 | The plug-in should allow validations to be specified as Server-side only. | Purpose: Give a developer control as to whether defined validations should be executed on the client-side. | Native Oracle APEX validation doesn’t support executing some validation on the client-side. | Plug-in feature |
| 28 | Preserve Errors | The plug-in validation can be implemented in separate dynamic actions under different conditions (triggering event, a different set of items). Each implementation can result in a different errors and the plug-in can make a summary of these results. Purpose: Give a developer the control to decide whether currently executed validations should include errors from other implementations of the plug-in. | Native Oracle APEX validation is executed once on page submit and doesn’t need such a feature. | Plug-in feature |
| 29 | Wait for results | Developers can define whether true actions following plug-in validation should be executed immediately after the validation or if they should wait for validation results. Purpose: Give a developer control over dynamic action flow. | Native Oracle APEX validation is executed once on page submit and doesn’t need such a feature | Plug-in feature |