How to develop faster with Oracle APEX in 10 easy steps

That Oracle APEX is an amazing tool and rocks low-code development is public knowledge, still we often encounter developers which waste a lot of time and don’t use APEX to its full potential.

You will be amazed how easy it is, try to follow these 10 points:


1. Use the wizards

In APEX you can build up pages manually or by using the Create Page wizard. Usually the wizard is way faster and will build all pages in the same fashion. This helps in achieving a consistent look and feel of your application. It also does some extra work by adding a page to the menu, creating breadcrumbs, and so on.

Sometimes it is also faster to delete an existing page and rebuild it through the wizard, rather than adding new fields manually, ie. when the underlying table has changed.


2. Stick to the standard Oracle APEX functionality

By using APEX wizards you automatically use standard functionality. As such this will have the highest probability to work flawless also in future versions of APEX. Once you deviate from the “APEX way” of doing things, you will slowly drift into a potentially unstable application.

Wow, that sounds cryptic, right?

Here is an example: when you create a form page in APEX, you end up with a default Automatic Row Fetch process on process point Before Header. You now could decide that process point “After Header” is so much nicer and move the process over there.

With a bit of luck your application still works, but might break at some point in the future because Oracle APEX adapts its behavior and decides that this Automatic Row Fetch process has to run “Before Header”.


3. Use settings

All APEX components have many declarative settings to influence their behavior. Always try to stick to use those settings, before you try to code around it with PL/SQL or (even worse) Javascript.

Let’s take the “Server-side Condition” as an example. It exists for almost all component types and decides, whether a component is being available/processed, or not. As condition type you can choose a myriad of different options like “Item = Value” or “Request = Value” or “PL/SQL Expression”, where PL/SQL Expression should always be the last resort, as all other declarative options are actually faster processed.

Using a setting rather than coding around it has the advantage of being stable. If a future Oracle APEX version introduces some changes, those declarative settings will be adapted to continue to work.


4. Avoid custom code

As with the settings, custom code should always be avoided, where possible. Why is that? Every single line of code has a certain cost associated to it: you need time to write this code, to fix this code, test this code, and to maintain the code in the future (APEX/DB/… upgrades).

Also every line of code, no matter if it’s PL/SQL, Javascript or CSS has a risk of failure. Either now, or in the future. Are you the one on your team who understands JS and therefore use it everywhere? Good job, now nobody else can maintain this code anymore, because they do not understand what you did there. Unless you write a plugin and make it easy to use.


5. Use plugins

Plugins are a great way to extend Oracle APEX and teach it new tricks. Need a new chart type? A dropzone file upload functionality? Extending the Interactive Grid toolbar? A multi-column LOV? These and many more plugins can be found on or with commercial providers like our FOEX Plugin Framework, or the APEX SmartPivot Plug-in.

In APEX almost everything can be extended as a plugin, which is also a great way of modularization to re-use code. Writing plugins isn’t too hard and there are many great examples among all those open-source plugins on So it is absolutely possible for everyone to look at an existing plugin and change it to fulfill your needs.


6. Leave UI fidgeting to the end

Especially for beginners who often try to accomplish a certain look: don’t get hung up on that and leave it be until everything else is done. Then ask yourself if it is really vital to achieve what you have in mind.

The APEX Universal Theme is pretty awesome and provides an up-to-date and modern web look. It also gets updated with each release of APEX and introduces additional features. That means the feature you are looking for might be introduced in the next version. It can also mean your handcrafted workaround (custom CSS) might not work anymore in the next version.

In case you don’t know what’s already possible, take a look at the “Sample Universal Theme” Packaged Application, which can also be accessed via


7. Stay lean

This is more a general advise, rather than APEX-specific. You might be confronted with lots of requirements and you try to (over-)achieve. Take a step back and start with a minimum viable version of your application. Show it to others, customer, business unit, and take their feedback. It might already be doing what they want. And this way you can avoid to implement too many pages and features.


8. Reduce complexity

You know this one: let’s say there is a requirement for a form. And another one for a very similar form, with just a few changes. And maybe a third similar form with some additional unique behavior. Which way do you go? One form to rule them all? Or three very similar forms?

This is a tough nut to crack. In retrospect, after being caught in this trap myself quite a few times, I’d say go for the multiple pages/copies route. It seems to be a waste and duplication, but it also allows for very simple duplicates. Once a single case changes, you only have to adapt this one, not the entire (huge and complex) form.


9. Forget your past

Have you just started with Oracle APEX? Are you coming from some other background than web apps on top of databases? Chances are, that your existing experience and expectations influence what you want to achieve now with APEX. Don’t try to replicate Forms, don’t think of Excel, don’t mimic Notes, Foxpro or whatever.

Clean slate, new start. Use the right tool, but also use the tool right!



10. Question requirements

Business units or customers often wish for things they actually can’t comprehend. They don’t know if what they want is feasible, easy to achieve, within the technology limits, or even simply physically possible. Maybe they don’t know yet, that the old client-server days are over and we can now offer different solutions.

Go back and ask them about the requirement(s) and show them some APEX beauty. They might like what they see and forget about old stuff.


What else would you add to this list?

Categories Development
  • Common Sense Reply

    This is ridiculous advice.. when are those responsible for product design going to realize that APEX is being pushed in the wrong direction? Many companies are removing the platform because of its shortfalls.

    “Just use the Wizard, don’t add custom code”

    When the product community operates in an echo chamber, without consideration of dissenting voices you end up with a failed product.

  • Simon Reply

    11. Use QuickSQL!!!!

  • Stew Reply

    Thanks for the excellent suggestions!

  • Peter Raganitsch Reply

    @CommonSense: the topic of this post is to point out the efficiency of APEX, not its versatility. Of course APEX is very flexible and can be extended in many different ways.
    Can you tell us more about what you mean with “wrong direction”?
    We are also happy to help convince anyone about the power of APEX. It would be sad to see someone using APEX at first and then leaving this platform.

Add your comment

Your email address will not be published. Required fields are marked *