DTaTiA#3 & Part 4: Good and bad practices at APEX! Part 4 - useful tips

So first:

+ do not repeat

Minimizing duplication in code is key to clarity and efficiency. Store reusable logic in PL/SQL packages rather than leaving functions and procedures alone - that’s what packages are designed for.

Similarly, avoid duplicating components in APEX. Everyone likes copy a region or item sometimes. Instead, remember about solutions such as Page 0 or Application Items. These practices promote cleaner, more manageable applications.

+ use build in options

Avoid reinventing the wheel by writing logic that already exists. Leverage built-in APEX components that are designed for seamless integration and will be maintained across versions. Only build custom solutions when absolutely necessary, as they can be difficult to maintain and can cause compatibility issues over time. Keep it simple, reliable, and future-proof.

+ advisor

I've noticed that people often don't use Advisor. And it's a great developer tool to help you check integrity.

+ debug

then you can see:

I've met a few developers who don't use the debug tool, and whole presentations are made about this tool! Note that debug has 9 levels depending on the type and severity of the bug.

+ do updates!

Keep your tech stack up to date! Regular updates are essential to avoid major challenges in the future. For example, I worked on a project that upgraded from DB11g and APEX 4.2 to DB19c and APEX 19.1. This huge leap required rewriting the entire application stack. While the leap from APEX 4 to 5 was significant, the lesson remains clear: consistent, smaller updates save time, effort, and resources compared to infrequent, large overhauls.

+ monitor activity

and then:

Also remember that in the user menu you have activity and there you can check Page View analysis by Weighted Page Performance and lower you have Application Errors.

Developers don’t remember about those functionality either.

+ bad database design

A wise person once told me this sentence: 10 minutes of planning saves 1+ hour of action!

Using this idea regarding project planning, sometimes it is good to start again, remove a few objects or even start with a clean slate. e.g. draw schema of DB on paper/whiteboard, any other simple graphic tool.

+ Pretius Developer Tool by Matt Mulvaney

Also I encourage you to use very useful tools made by my colleague - Matt Mulvaney.

• Revealer: Displays client and session info that is not immediately available to you as a developer

• Reload Frame: Provides you with a convenient single click for reloading a modal dialog page

• Visual Build Options: Glows page components in blue/red, giving you a visual clue on whether a certain component will be included/excluded on export

• Developer Bar Enhancements

  • Quick Page Designer Access: Use a keyboard shortcut to quickly navigate to any Application & Page in your workspace

  • Glows the Debug Icon red when Debug is on

  • Auto View Debug for Page Load and Page Accept

  • Master Detail Debug all on the same page

  • Shared Components icon appears on the Developer Bar (replacing the Home button)

+ views on views

The next issue is multiple views on views on views problem.

Here’s an example of bad structure naming, which is very confusing… :

Real life example:

Select * from module1_customers (view) ->

-> view from app100_customers (also view) ->

-> from (this time!) table customers ….

TIP: use prefix V_ or suffix _V ! Simple and it works!

But remember that when you write a simple query like select * from table, under table it could be also view, materialized view or synonyms. It’s nice to add a prefix or suffix like underscore _V to make it clear for another developers.

I don’t have a clear solution on that, but try to reduce number of views from views to a minimum.

For me, the view from the view from the view looks exactly like this:

maybe the environment changes, but basically everything looks the same!

Conclusion of part 4 (the last of this series)

Sometimes the simplest tricks and tips can solve the most complex problems.

Thank you for taking the time to read this series of 4 articles. I hope they helped you at some point in your app development.

Until next time!