Build option use case - replace condition never

I first blogged about build options three years ago while still using APEX 3.x - I can tell by the green ;-)

I still use them regularly, but not often for versioning as they're allocated at a component level and not for attribute modifications - perhaps in later releases we'll see an extension of their use.

What I do see all the time is components with a condition type of "never". This is probably because it's the quickest way to turn off features that are broken or those you're not ready to completely remove for whatever reason.

The issue with this is they get forgotten. Future maintainers see these components in limbo and wonder if they should be removed or enabled, particularly if they lack comments regarding their status.

I have encountered valid circumstances when a report region is purposely set to "never" - where a link is available to export the relevant data as CSV.

Instead I would suggest creating a build option that looks like this:

Build option - to be removed

The 'Status' of 'Exclude' means I don't see the components at runtime - just like a condition of "never".
'Default on Export' being the same as current status means it will stay excluded as the application moves between environments.

One major advantage I find is the accompanying utilisation report. At some point during the project I went through everything I've allocated 'to be removed' and decided if it truly was time to sent these components to /dev/null.

Build option utilisation report

Do you have any interesting uses for build options?

Performance of APEX conditions

I often think about performance of conditional expressions. I'm not just talking about the expense of whatever the test is, but the difference between the condition types used.

I’ve heard about it from a few sources, and Tony Andrews blogged about it recently, but never really been able to/had a chance quantify it. Roel Hartman has also blogged about this after reading my tweet. He shows some figures, but difficult to rinse, repeat & measure like a PL/SQL process.

For example, while I’ve always encouraged this type of expression for consistency (which runs dynamically), particularly with new developers learning the differences between item substitution syntax.

This performs better (declaratively):

I don't see this second debug statement when using the declarative method.

The benefit is minor, but if multiplied by 50 separate events, that’s 1.5 seconds extra in rendering time.

Use the low-code options when you can, your database will appreciate it. You could even nest regions to get around multiple conditions.

Apex Tutorial: Adding a Read Only Option

Last week Recently I published a tutorial walking through setting up a form and report on the same Apex page. This one done using out of the box functionality, without the use of dynamic actions. Hence this is aimed at those learning the Oracle Application Express development tool.

Edit Feb 2012 :
Bug 13587192 Quick picks are displayed for read-only page items and in Printer Friendly mode
Has been included in the 4.1.1 patch; Demo; OTN Forum entry.

We can take this a step further and extend this functionality to open the record in read-only mode first.

1) Modify report link to pass P6_MODE = R, instead of E
Now we have three "modes" View (which doesn't display the HTML region), Read only & Edit.

2) Modify all form items to apply read only condition to P6_MODE = R
Now when you click the link for an employee record, the form initially opens in read-only mode.

3) Modify HMTL region condition to be :P6_MODE IN ('E','R')
We need this region to display in edit and read-only mode.

4) Extend Delete/Save buttons conditions to include :P6_MODE = 'E'
ie => :P6_EMPNO IS NOT NULL AND :P6_MODE = 'E'
We don't necessarily want these buttons being displayed in read only mode. 

5) Create Edit button in the HTML region
You could add an authorisation condition on this button to make editing records available only to privileged users.

* condition :P6_MODE = 'R'

* redirect to page 6 

* passing parameter P6_MODE = E

The problem now if if you have, for example, quick picks on any of your items - these will still be displayed as the read only option only adds the class="display_only" tag to the item definition:

6) So to clean this up, we need to make a copy of item P6_JOB

Use nearby sequence number to create the copy in the same position on the page.

My job field sequence was 30, so I chose 35

7) Remove the quick picks option from copied item P6_JOB_DSP

These are the options we don't want displayed in read-only mode. The user can't save the change, but it looks untidy.

8) Add display condition on P6_JOB_DSP as :P6_MODE = 'R', retaining the existing read only condition.

Alternatively we could set the item type to display only, however we still only want it appearing in read-only mode.

9) Add display condition to P6_JOB as :P6_MODE = 'E'

The original item only needs to appear in edit mode.

We now have a functioning read-only mode option, with an Edit button available to re-open the page in edit mode.

The item list in the page builder will now look more like this:

Run the demo to see it in action. There are other techniques demonstrated on this page.

I hope that further helps your understanding of some of the concepts available to the Application Express environment.

Scott.