Community Post – Dynamic Options

It’s always a pleasure to receive article submissions from the OPA Hub Website community, so this week I am pleased to relate to you an article suggested (and indeed documented) by Jeff Gwilliams, from Australia. His example shows how to create Dynamic Options. If you would like the Zip File, just leave a comment!

Jeff, as do all good Oracle Policy Automation (OAI) consultants, carefully measures the need for any requested functionality to see if it can be achieved by using a combination of out of the box tools. If, and only if, it cannot, then Extensions may be the answer. But, as the saying goes, the best piece of code is the one you don’t write.

So it is in that spirit that Jeff provides us with an excellent example of delivering some dynamic display of options, with no JavaScript required. His example is as follows. In this short demonstration, it uses the simplest expression of all the requirements, so there are no entities or inferred instances which could also be used.

The Setup

A user must be able to enter one or more contact methods (email, home phone, cell phone and so on). Then, they must choose their preferred contact method. So, if they can enter 5 different methods, but they only provide two, then the “preferred contact method” should only show two. And, for extra bonus points, the choices should show the actual number or email address that the user entered. As often, a picture will show it more clearly.

Dynamic Options

Of course, there should be no radio buttons if you only have one Contact Method, since there would be no option! Here’s how Jeff put it together

  1. Set up the attributes for the basic layout shown above

Set up visibility rules for the different preferred contact options – so that the radio buttons will not show if you have not entered anything (these are just two of them, you get the idea):

Dynamic Options

Set up rules to understand how many items the user has entered (again these are just a couple, you get the idea):

Now comes the smart stuff: he creates a Value List which uses the %attribute_name% format for the actual display. You probably already know that this format is used for substituting in Forms and Screens (and, as we mentioned a while ago, in Error() and Warning() rules as well). So the radio buttons will display the values entered by the user.

Dynamic Options - Value List

Then having set this Value List is the source for his attribute “the preferred contact option”, he applies his visibility rules to the values on the Screen:

So now his preferred options are shown only when needed, and they display the correct values. Nice job, Jeff!

We encourage you to submit your own articles and we will be happy to reproduce them here. What tricks do you have to share with the community?

Have a nice day!