Number field - Format mask and validation

Question

APEX 4.2.1
When a page item with source=DB column uses a Number type and a currency format mask (FML999G etc), when the page is rendered, it properly formats the number.
The built-in Item is numeric validation appears to be handle this reasonably ok. i.e. both formatted values and only-digits both validate ok.
But any after-submit validations choke on the non-numeric characters in the field! Please don't tell me I have to a) create shadow items and/or b) replace() out the non-numeric characters in the validation.
After so many years and versions, why doesn't APEX have a simple, declarative, elegant solution to handle such a basic function?
Am I missing something?
Thanks

Answer 1

As described in the item help
"Select or enter a format mask. Note that format mask is applicable only to items of source type Database Column."
In my experience, and this goes for the great web experience, not just the application you're designing - I've found the most data entry fields avoid formatting.
Relevant information is often shown item labels.
Any occasional the business has specifically asked for formatting, I've taken the same approach as I've needed to for years - before web development (and every time you use the to_date/to_char functions for date conversions) - validate the information as per expectation. If you think the user will be adding punctuation to a numeric field, then you must validate accordingly.
This usually means adding TO_CHAR(value_entered, expected_format_mask) to your validation control, instead of presuming APEX will read the user's mind and know the content of that numeric field may not be numeric.
Date entry does the same thing - ultimately there is a session date format that is implicitly used by Oracle to convert an entry of 12-10-2012 to the appropriate date -- ie, is it October or December?
Have a think about the various websites you visit personally - plane bookings, concerts, ebay, etc - how many expect entry to be purely numeric? My recollection is most, except maybe some credit card fields, but most use some sort of regular expression to sort that out. And you can tell the validation is coded respectively.
Generally, I reserve this sort of primping to reporting - even then it's made to be subtle - just like I'd prefer makeup to be ;-)
Most users just care about the data, not how it looks.
Scott
blog: [url grassroots-oracle.com]grassroots-oracle.com
twitter: [url twitter.com/swesley_perth]@swesley_perth
-- please mark any useful posts as helpful or correct, in the end it helps us all