Category Archives: APEX Validations

APEX Validation Fails to Return Control to the Page: Reload on Submit: Always

Posted on by
Reply

I ran into this griefer and want to share the solution, as a reminder to check the obvious-but-not-so-obvious options in situations of unexpected behavior. Particularly on legacy code.

Working in a ooooold app – born in HTML days and lovingly upgrading through the years, on a legacy Data Upload page, I found that a validation on the column mapping page stopped working this year.

By “stopped working” I mean that the validation failed, but control never returned to the page. The error was logged appropriately, then the processing icon appeared and kept turning … the page hung. What!? This worked fine last year. Has been working fine since 2009. In the meantime we had upgraded (since all worked fine last year) to APEX 23.1. Did tons of tesitng, all should still be OK. (But did we test a failed column mapping? Hmm… this is a small part of a very large app …did we?).

Of course I focused on the validation. The visible thing making the noise. Tried all kinds of things I will not list here but will admit too, because, that’s what we do, we focus on the thing that is failing. We think.

Long story short, the issue was not the validation – it was doing its job (as I confirmed several times over). It was the Page: Reload On Submit setting.

It was set to Only for Success – a setting we use for editable Interactive Grids, and on more modern pages, as opposed to Always – which it needs to be for a standard legacy transactional page with On-Submit validations, so those validation errors will display atop the page, and sit there, on validation failure.

I was so focused on the validation, I missed the real issue: The Page was not behaving properly after a validation failure. I had to take a step back and look at the real issue.

Hard to do when in a crunch, or overtired, or working on a production issue that holding up a deadline, or all of the above.

Lesson learned: Take a step back. Walk away, come back. Get another set of eyes. Look at the real issue. Again.

How or why this setting was changed, I do not know and do not (almost really) care. Indeed all 3 pages ( we have 3 legacy Data Loads) had to have the Page Reload On Submit reset to Always. Was this from the upgrade? Most likley. Failed column mappings added to the testing list.

All is now good. Back to normal operations, many brain cells released to focus on normal work and moving forward

Aside: Why a keep legacy Data Upload? For the luxury of colum mappings, a very handy feature when one needs to accept different format incoming data files that all map into a standard set of column names. So far, there is no updated declarative data load option that has the column mapping interface that our end users use once a year and are used to. Could we write one? Yes. Given time and resources and priority. So it stands, for now. Remember that “legacy” does not mean no longer valuable. It does mean we may need to rewrite this whole thing at some undetermined point in the future. It means we need to do a lot of testing on every upgrade, as usual. I do hope that the APEX team simply forgets to remove this piece of legacy code.

Hope this helps someone else,

Happy coding,

Karen

APEX 21.1 Most Subtle New Feature: Client-Side Validations

Posted on by
Reply

APEX 21.1 has a several awesome new features that steal the spotlight: Native Map Region Type, improved application Data Loading, and Faceted Search enhancements to list a few. But don’t overlook the subtle but important change in client side validations:

New Look

Client-Side validations now LOOK LIKE server side validations:

Client-Side Validations APEX 21.1 and Higher – Same as Server-Side

Where they used to look like this, with the familiar Correct errors before saving popup:

Client-side validations, up to & including APEX 20.2

Good News

This is *great* for your end users – all validation now look the same, you never have to explain to end users why they may get that “Correct errors …” popup. This is great for developers, you never have to do the extra coding to make the client-side validations look like the server-side validations – if you chose to go that extra step (I suspect many of us picky developers did).

UNLESS you have end users who are used to seeing that “correct errors before ..” popup. Now they will not see that popup, they will see the perhaps more alarming golden error popup, the same error popup as for server side validation errors.

Tell Your Users

This is different. Your end users should be told to expect this difference.

If you are upgrading to 21.1 from earlier APEX versions, and if your end users are used to seeing the client side validations the old way, please let them know of this upcoming change!

What If You Did This Already?

While all told this is a good thing – if you are a developer like me who has (already) done the apex.message coding to make your client side validation messages look like your server side validation messages, no worries:

a) You don’t need to do this anymore, and

b) Your existing code will work fine – you will not see double error messages.

While you may eventually want to take that apex.message code out, it does not hurt anything to leave it there.

Hope this saves someone a call or two,

Happy coding!