Recent APEX Changes that Make the Developer’s Life Easier

Introduction

Those of us who have been developing in APEX for years have probably gotten used to certain foibles of APEX and the builder that we know, accept and have workarounds for. However, with each new version of APEX, those tricky annoyances are slowly being removed or mediated. At DSP, we recently blogged on the new features of APEX 24.1, rounded up by my colleague Colin Archer in this blog.

I thought I would delve into some of the recent improvements that seek to remedy some historic limitations:

• Comment Out components
• Save and Run from Code Editor
• Show Processing setting
• Component Groups
• Readable Exports

The 'Comment Out' component feature

When developing an APEX page, we often want to temporarily disable components – report regions, dynamic actions etc. Maybe you want to debug certain behaviour and rule out a dynamic action as the cause. Perhaps you want to temporarily copy an existing report but make it an IG instead of an IR and play around with the possibilities.

Traditionally, the answer to disabling a component without deleting it would be to set the 'Server Side Condition' to 'Never'.

This is fine if there is no server-side condition already on the component. However, if there is, setting it to 'Never' loses whatever conditions you already had, which you probably don't want if you're temporarily disabling the component. If your condition is an expression, you could do something nasty like append 'and 1=2' to it, but this is far from ideal, as it's easy to forget that it is there.

Now, however, you don't have to rely on 'never'. As of v23.2, you can use the 'Comment Out' build option. Simply right-click on the component in question and select the option from the menu.

Your component will then display with a strikethrough to show it's not going to be rendered on the page. It should be noted that the 'Never' option is still there and will also display the component title with strikethrough, so it won't be immediately obvious which option has been used to deactivate it.

There is a bit more to it though, if your app was created in an older version of APEX and then upgraded. The 'Comment Out' feature is a build option. If you created a new app in 23.2 or above, the app would be generated with that build option by default.

The presence of this option means that the right-click menu shows 'Comment Out'. So, you won't get the option automatically, if yours is an older app. Fortunately, all you have to do is create a new build option manually, call it Commented Out (with a status of Exclude), and the next time you go to a page component, you'll see the option appear on right-click!

Save and run page on Code Editor

This is a simple one but a nice addition. The inclusion of the Save and Run page allows you to avoid the extra step of hitting 'Apply', then saving/save and run on the parent page. I often find myself making changes to queries in the builder in one window, then hitting refresh on my page in the other – sometimes without saving the change first. This addition will hopefully remove that possibility.

Show Processing

This is a great feature that can alleviate headaches created by users who are still into double-clicking. The Show Processing setting prevents the page from being submitted twice by overlaying a processing spinner and making the rest of the page non-updateable while the submit process executes. This feature is available on both buttons and dynamic actions that perform a page submit.

I can think of 3 reasons why a user might click more than once on a button:

1. habit (relating to being from an older generation when double-clicking stuff was all the rage)
2. sheer anger (we've all been there)
3. a slow response to the first click on the page, which tells the brain that you didn't click properly, causing you to have another go.

We can't do much about a, but for b and c, we should, of course, endeavour to code our apps so the behaviour of the page doesn't induce rage and doesn't process slowly, wherever possible. Regarding database actions, our update logic should be robust enough to handle any double submissions as well. That said, having the ability to prevent a double submission is useful for the multitude of actions we might be trying to perform on page submit.

I tested this by creating a simple example where a page process was set to insert sysdate into a table on page submission. I then had a simple IR to show the data in the table. Without 'Show Processing' set on the button, I tried to click as many times as possible. I managed quite a few before the page refreshed and reloaded the report, showing that all my entries had indeed been committed to the database, i.e. the page had submitted multiple times.

I then set 'Show Processing' to 'Yes', and as hoped, no more clicks were accepted after the first entry.

I did come across something interesting in a different experiment, however. In this example, I set up a branch to call a modal page after submission. The multiple-click issue happened here as well, with 'Show Processing' set to 'off' – it opened multiple instances of the modal page. 

However, with 'Show Processing' ON, my modal opened, but the process overlay stayed indefinitely, so I couldn't do anything without refreshing the page.

Now I realise this is a slightly spurious example – I would never normally call a modal from a branch in this way. However, it does illustrate that this setting is not foolproof, and you should ensure that there's good reason to use it in any given circumstance.

Component Groups

Another nice and constantly evolving feature is the improvements to Component subscriptions. An offshoot of this in 24.1 is the introduction of 'Component Groups'. Similar to the concept of Application Groups, these allow you to group components, such as LOVs, lists, Rest Data Sources, etc., into a named sub-group.

Once this is set up, you can subscribe/copy from these groups from other applications – allowing you to speed up the process of accessing common components in multiple apps. You can also refresh all components within a group at the same time.

Readable Exports

Another element of APEX that has been evolving over the last few releases is Readable Exports. From a version control/quality checking perspective, the standard .sql export of an APEX is a nightmare to differentiate against other versions. Viewing the code in this format makes it very difficult to read and understand what has changed. The slightest change can move other components around in the file. The attempt to counter this has been to introduce 'Readable format' in the export. 24.1 has introduced the ability to export single pages at a time in this format.

If you set 'Readable format' to 'Yes', you get a zip file rather than a single SQL file. The SQL file is still present, so you can install it, but you get a folder structure that contains all the other elements you've exported.

In the example below, I've exported a single page from my application. The YAML file contains easier to read and compare the representation of the apex page in question.

If I compare the folders for two different versions of the same page, I can clearly identify which files have differences and then look at what those differences are:

In the example, I commented out one region and uncommented another. I then added a brand-new IG region, represented by the long red section in the diff tool. Crucially, the elements below this region remain in the same place in the file, so I was only seeing genuine changes to my page.

Summary

APEX is a very mature tool, and the incremental strides being made to improve the developer experience are very welcome. There will always be improvements that can be made, but in recent versions, great strides have been made to remove common bugbears. Long may it continue!

For more information, check out our Oracle APEX Services, and if you liked this blog, check out our other APEX blogs here.

Subscribe to Oracle APEX Insights if you want to stay tuned for more APEX updates.