Build Options on Report Columns

Let's say you're experimenting with a report (IR or classic) column and you would only like it to appear in you development environment.

What options do you have for hiding that column in other environments?

1. Don't migrate the change - use your source control processes to only move it when it's ready. This isn't always practical, nor the intent, particularly since you can programatically set the status.
   
   
2. Add server condition on database name - we can use an expression such as
   sys_context('userenv','db_name') = 'dev'This isn't bad, I have a common function I call for this sort of thing. But it's quite granular.
   
   
3. Build Options - under-utilised silent catalyst that can help us turn a group features off/on at the flick of a switch.

In Oracle APEX 5.1, Build Options are an attribute of each column, in addition to just about every other component in the builder.

APEX 5.1 Column Attributes

Prior to APEX 5.1, column definitions were one of few components that don't have a declarative option. However, we still have the magic of dictionary views.

Pre 5.1 Build Option on Column

So we can query the application's build options and determine if the relevant record is switched on.

select null
from apex_application_build_options
where build_option_name like 'My build option'
and build_option_status = 'Include'
and application_id = :APP_ID

Again, you could put this in a re-usable function/view, not that you would need it often.

Neat.

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?

Build option use case - experiments

I find build options as nifty tools to not only categorise components for the very purpose build options are documented for, but to help inform developers & testers of applications.

Here I've added a region on the global page to inform users of the status of the page - based on it's allocation to a build option.

Build option in action

I created the following classic report in my global page using region template DIV region with ID and report template One Column Unordered List, with some styling on the columns.
This shows detail of the build option allocated to the page (via page attributes).

select b.build_option_name, b.component_comment 
from apex_application_build_options b

    ,apex_application_pages  p
where b.application_id = :APP_ID
and   p.page_id        = :APP_PAGE_ID
and   b.build_option_name = p.build_option
and   b.application_id    = p.application_id

I applied the following condition will ensure the global page region is only displayed when the page has been assigned a build option.

select null
from apex_application_pages  p
where p.application_id = :APP_ID
and p.page_id = :APP_PAGE_ID
and p.build_option is not null

The region is also allocated to a relevant build option so it doesn't display outside development.

My build option in this case has a status of Include, but Exclude on export.

Build option setings

I'd like to see build option features expanded in future release, perhaps including extended release management options.

Which pages are locked in APEX?

Would you some SQL to tell you which pages are locked?

As far as I could tell, there is no data dictionary view that this information.

So I found this using the all_tab_columns view

SELECT 
  id
 ,flow_id
 ,object_id
 ,locked_by
 ,locked_on
 ,lock_comment
 ,security_group_id
FROM apex_040200.wwv_flow_lock_page
WHERE 1=1
--AND   flow_id   = :APP_ID 
--AND   object_id = :APP_PAGE_ID
/

I used it to add a region (bound to a build option) that displayed a notification in the sidebar to other developers that the page was locked and under construction/change/development.

Scott.

ps - can you find the joke on this post?

Oracle APEX build options

Sometimes while developing for a release, components aren't ready for migration for whatever reason. You may also wish to make available development only pages, for instance.

Oracle Application Express has a feature called "Build Options" that are designed explicitly for this purpose. There are other methods of doing this, such as utilising authorisation schemes, but this is neater.
Here is a simple example of a build option defined in the application:

This option can be assigned to application components, such as pages, as follows (within edit page attributes)

This means that within the development environment, these pages are available.

When the application is exported, the components are present within the builder - but not available at runtime.

When I was first exploring this feature I got confused on this concept.:

I exported the application, checked the file - my component was there.

I imported the file, checked the application - it was there.

It wasn't until I ran the application that I noticed the components were missing. This allows you to configure further with your new application. In a way highlighting how important testing even when you're "sure" it works in theory.

The easiest way to think of the include/exclude options is as on/off, just a like a regular condition.

I think the documentation on the build option has improved since I last looked.