APEX Component Settings for Switch

While I point out a 'hidden' setting for Switch items in APEX, I want to comment on two related item types found in Oracle APEX => radio buttons and checkboxes.

1) Radio button

I really think the standard Template Option for radio groups should 'Display as Pill Button'

It really provides a simple and effective UX when a small set of options are on offer. Touch devices can select the option as if it's a button, and mouse users only need one click, compared to a select list requiring two. And the click doesn't need to be precise for those tiny radio group circles. I wish the application builder adopted the pill button approach more often.

And it's real easy to hook a dynamic action on change of the radio group, perhaps to refresh a classic report with data limited to the selected option. (Don't forget to add page items to submit!)

2) Switch

The Switch item was the answer to a number of methods of deploying an "iPhone-like" on/off switch.

I actually wrote an (internal) item plugin to do just this, but I much prefer using the native option.

A frequent question relates to how switches are rendered. If you don't see what you expect, have a look in Shared Components -> Component Settings.

Application -> Shared Components -> Component Settings

Personally I prefer the 'Pill Button' look, for reasons above. I find the APEX Application Builder seems more washed out with all the Switches in the properties bar, compared to the more softened On/Off pill buttons. If I could change this at the builder level, I would.

The offerings will vary depending on your APEX version, and if the application's Universal Theme has been refreshed. 

Application level settings for plugins can also be found in Component Settings, in addition to built-in APEX feature tweaks. These can something you choose to review after an APEX version upgrade.

3) Checkbox

It seems the humble HTML checkbox will always be extant, regardless of the pain it brings to tabuler forms. However, it suffers the same precision requirement as the native radio group selections - though better deployments allow selection using the label as well.

Go with the Switch (as a pill).

What do you think?

Adding tooltips to your APEX report

There are a number of ways to publish tooltips in your application, many of them much more verbose than they need to be.

Some of them implement fairly fancy JavaScript and CSS, but there is a simple way to plug in the default tooltip behaviour into your Apex reports.

When you edit your report column attributes, add the following code into the HTML expression.

<span title="#MY_TOOLTIP_COLUMN#">#MY_COLUMN#</span>

These attributes typically have decent help in regard to the sort of coding examples you can apply.

So this setup places the data from the selected column my_tooltip_column, and displays the value in my_column as you'd normally expect.

And is the display from Google Chrome:

Simple but effective - and flexible.

See a variation on this example here.

Basic Apex scripting - show/hide & labels

Sometimes the scripting requirements for an Oracle Apex page are fairly simple, yet determining the required modifications can be frustrating, particularly for a beginner in either Apex or HTML behaviours.

Recently I had the requirement of showing or hiding both the label and input item, depending on the selection within a select list.

So with this example, let's say my requirement is to hide the "Other Description" label and input item if "My select list" equals "- Select me -"
Otherwise, display the items and as an added bonus - set the label to the value of the selected list item.

First I need to modify the label so I have the ability to reference it in my JavaScript. So I edit my P1_OTHER_DESCRIPTION field and extend the HTML Table Cell Attributes in the Label section (not the Element section).

Here I added id="label_other"

Now I can define a script to do my work. It's highly likely this script will be used solely on this page so there's no real harm in adding it directly to the page attributes - unless you have a dedicated JavaScript file you add your scripting code.

So this would be added to the page footer text:

<script language="JavaScript" type="text/javascript">
<!--
function toggleOtherDesc(){
  $f_Hide_On_Value_Item('P1_MY_SELECTLIST',['P1_OTHER_DESCRIPTION','LABEL_OTHER'],'hide_desc');

  //I could also change my actual label, for instance to the value of my select list input item
  document.getElementById('LABEL_OTHER').innerText = $v('P1_MY_SELECTLIST'); 
}
toggleOtherDesc();
//-->
</script>

Some points to note here

• $f_Hide_On_Value_Item is a pre-defined function you can call to hide a list of items based on the value of another. Its behaviour is documented online here. In this case I listed both the label I created an id for plus, the item name - surrounded by square brackets as to define an array.
• 'hide_desc' is the value I've set in this case when the input description is '- Select me'
• .innerText allows me to set the descriptive label, as long as I supply the id I defined for the label, not the item name you see in the Apex builder.
• $v will return the value in the field, as it would be posted. This is also documented in the JavaScript API reference page.
• The highlighted line 9 means the function will be called when you open the page, in this case after it's rendered. That way the fields will be shown/hidden depending on the set value in the select list.

Lastly, I can modify the P1_MY_SELECTLIST item to call the JavaScript each time the selection changes.

So I add onChange="javascript:toggleOtherDesc();" to the HTML Form Element Attributes in the Element section.

So the final product will change the label to the selected value in the select list, or hide the label and input field if '- Select me -' is chosen.

There you have it!

Apex Post Calculation Computations

A warning - perhaps my musings are different as I wrote this sitting in Melbourne airport, my mind exhausted after a few days of conducting training with not much sleep in the hotel bed.

Once upon a time I was a regular Oracle Forms programmer (and sometimes still current). These days I spend most of my time with Application Express. This makes me happy as I did enjoy mod_plsql - an ancestor (of sorts) of Apex.

Occasionally I notice some parallels between the two, even more occasionally I get around to writing an entry for the world to see - a strange urge for some but it seems that people read even more mundane topics.

There are many attributes available within the Apex environment. By attributes I mean little boxes in the various wizards ready for my to type something in. Sometimes it seems overwhelming. Then I remind myself how flooded with settings the Forms environment must seem. Of course I snap myself back to normal when I think about what I've seen of JDeveloper.

Have you ever wondered what some of these settings do?

Recently I was creating a copy of a data entry form within Apex so I could present a cut-down / read-only version of the page. There were some fields that instead of being Select Lists, I needed to display their descriptive value - not the return value that is stored in the column.

There are a number of solutions to this problem, as with most problems. One solution I came to involved utilising the "Post Calculation Computation" attribute of the item. This means that after I source the item from the database column, I can transform it's value into something else. The obvious solution here would be to pass the value to a function that determines the descriptive form of the value - from some sort of reference code table.
my_pkg.get_label(:P1_VALUE)

I mentioned forms programming before, right? Immediately I thought of post-query triggers and the pros and cons behind various coding techniques in these triggers. First and foremost was the very same practice of taking a value and converting it to a description. This was an expensive task as not only did it require an extra hit on the database, you needed another round trip from Forms runtime to the application server. The better solution was to incorporate the request within the query - perhaps via a key-preserved view.

The same rings true within Application express. Sure, we don't have another round trip between servers since all the action is happening on the database; however it still requires another select statement to be executed. For a dinky (a Aussie/British colloquialism meaning small and insignificant) little Apex page, what's an extra hit on the ever powerful Oracle database? Perhaps try see what happens when scaling your request to thousands of users.

So perhaps some of our old habits can carry on to this modern day programming tool? I'm certainly not saying this post calculation attribute is not useful. I have another field populated via a list manager with a popup lov. This means the values are separated by a colon. In my application, this field holds a list of e-mail addresses. When I want to present this list to the user in a pretty format, I can use this attribute to convert it to something suitable for a HTML page:
REPLACE(:P1_EMAIL_LIST, ':', '<br>')

Of course if you wish to do this, you may need to ensure your item type does not convert special characters.

It seems my plane is about to call for boarding, so I'll save you all from further ramblings... for now. Enjoy your weekend.