Introduction
In this Blog, I'm going to explore the APEX Validations by Page Report. On the surface it appears as a valuable utility which allows developers to assess whether Page Items have the correct assignment of APEX Validations.
But does it cut the mustard? let's find out.
Demonstration
I'm going to build a Application from Object Browser > Tables > EMP > Columns > More > Create App. This generates sample pages in Application Builder based on the EMP table.
When its created, I'm going to Utilities > Validation Utilities > Validations by Page. This should give me some good information about if the Validations have been correctly applied
Its saying, on my DML Form (page 5) I have 2 Validatable Items (out of 8), but I don't actually have any validations on those items. Nice - I like this report already.
I'm not too concerned about Faceted Search as there are no Processes on Submit. So I'm a tad puzzled why its appearing on this report.
OK lets look at page 5. There are indeed 8 Page items on this page. But which two are the Validatable ones? I literally I have no idea.
Funny Fact: I checked and, according to the Oxford English Dictionary,Validatable isn't a real word
If I delete all the Page Items and then Synchronize Page Items back again, the page doesn't even show in the report anymore. Why? I'm lost.
Lets dig in to the SQL behind this Interactive Report. If you want to know how I found this SQL.. then read this.
select id,
name,
(select count(*)
from wwv_flow_step_items
where flow_id = :FB_FLOW_ID
and flow_step_id = p.id) as total_items,
vi.validatable_items,
(select count(*)
from wwv_flow_step_validations
where associated_item in (
select id
from wwv_flow_step_items
where flow_id = :FB_FLOW_ID
and flow_step_id = p.id)) as existing_validations,
p.page_type
from wwv_flow_pages_dev p,
(select flow_step_id,
count(*) as validatable_items
from wwv_flow_step_items i
where (i.display_as in ('NATIVE_CHECKBOX', 'NATIVE_FILE', 'NATIVE_POPUP_LOV', 'TEXT', 'TEXT_WITH_ENTER_SUBMIT', 'NATIVE_SHUTTLE', 'NATIVE_RICH_TEXT_EDITOR', 'NATIVE_TEXTAREA', 'NATIVE_DATE_PICKER', 'NATIVE_DATE_PICKER_CLASSIC', 'NATIVE_SELECT_LIST', 'NATIVE_RADIOGROUP'))
and flow_id = :FB_FLOW_ID
group by flow_step_id) vi
where vi.flow_step_id = p.id
and p.flow_id = :FB_FLOW_ID;
Right.. lets do this step by step....here is what my Page Item types look like after creating the APEX application using the App Wizard
Here is what happens after I delete all the Page Items and then Synchronize Page Items.
Ahh, so clearly P5_MGR and P5_DEPTNO, which were Select Lists (but are now Number fields), are the 2 Validatable items. It's just that the Synchronize Page Items cannot create Page Items as Select Lists - I get it, that's fine. But do I really have to guess, each time I run this report, which Page Items are Validatable?
If I put them back as Select Lists, they appear as Validatable Items again.
Going by that SQL Query, It appears that some Item Types are deemed Validatable. These are some legacy ones, like NATIVE_DATE_PICKER_CLASSIC (now NATIVE_DATE_PICKER_APEX), TEXT (now NATIVE_TEXT_FIELD) and TEXT_WITH_ENTER_SUBMIT (no equivalent). There are also newer ones like NATIVE_SELECT_LIST & NATIVE_SHUTTLE, however modern ones like NATIVE_COMBOBOX & NATIVE_SELECT_ONE are omitted.
So why are some standard Item Types like Number Fields & Text Fields not Validatable yet others like Select Lists are? I can't even answer my own question here. Before I ask even more questions I cannot answer... lets jump to the Summary
Summary
The Validations by Page report can be accessed by Utilities > Validation Utilities > Validations by Page and works like this
The Total Number of Page Items is accurate and includes Facets within those counts.
The Validatable Items includes a custom list of legacy & recent Item types that, according to some criteria, are deemed Validatable
The Existing Validations are a count of Validations where a Page Validation has an Associated Item with a Page Item
Adding a Required = Yes attribute to a Page Item does not increase the count of validations
If there are no Validatable Items, then the row is not shown at all!
- This means you cannot evaluate Validations to Page Items without having at least one Page Item in this special list. For example the Login Page (9999) contains none of these listed Item Types and therefore is never shown in this list, meaning you cannot use this report to evaluate the Login Page for correct validations
You may think that it is good practice to get the number of Existing Validations to match the Total Items. This logic is flawed, as a Page Item may have more than one validation therefore the Existing Validations may exceed the number of Page Items. Therefore the counts may match, yet some Items may still not have validations
Without the ability to run the query above in the APEX Schema (there is no substitution for APEX Views as the WWV tables differ substantially) you cannot easy identify the Validatable Items
Entries appear on this report regardless of if Submit Processes are present. My rationale here is: Why validate anything, if the submit process doesn't do anything?
The number of Validatable Items are, in my opinion, meaningless
This report, in my opinion, has no use and should be avoided. The idea behind it is solid though & there should be check of whether Page Items do indeed have a Required=Yes or at least 1 Validation. Perhaps I can write a SQL statement for this 🤔
ENJOY!
Whats the picture? It's Brimham Rocks. Sorry, there are no Rocks in this photo. Also, I'm not really sure I'm allowed to Mountain Bike in this area 🤭. Visit Yorkshire!