1 Reply Latest reply on Aug 20, 2014 2:47 PM by Sean Reardon-Oracle

    drop down list - restrictive input visibility and external xml list file

    Dr Jason Sender

      The following question applies to OPA 10.1, but if a solution requires a later version of OPA (e.g., 12.1) we may upgrade so please let me know what version your answer applies to.


      I have a series of tabs of in an Excel spreadsheet that map various categories onto each other and I want to implement this in OPA so that there are six screens with drop down lists and the list items visible on screen two will depend on the item selected in screen 1; the list items on screen 3 will depend on the item selected in screen 2, which depends on the item selected on screen 1, etc.


      For example,


      Screen 1 might be States:



      New York




      Screen 2 might then be Counties:  Assuming Virginia was selected...






      Screen 3 might then be towns: Assuming Accomack is selected...





      Basically, I have large spreadsheet lists with list items (one list has 2040 unique items) and thus I can't manually enter the list items easily.  I would like to 'specify list name' and have OPA use an xml list (easily created from my spreadsheet), but the OPA help menu says "NOTE: This xml list implementation does not currently support visibility or default values..."  So, it seems I will be unable to make the inapplicable list items invisible.  So, to use the fictitious example above, if I selected the state of Maryland, I don't want the counties applicable to Virginia or any other state but Maryland to be visible; yet, all the counties in the whole country need to be included in the list in the first place.


      If anyone knows of a solution or another approach to this problem (other than creating custom functions) then please let me know.

        • 1. Re: drop down list - restrictive input visibility and external xml list file
          Sean Reardon-Oracle

          "Out of the box" for 10.1 you could try the following:


          Simply have a separate list for each of the sub-components. It can still get a bit painful but you at least don't need custom functions or custom controls.


          So on the first screen you have the attribute collecting the state using the list of states (provided via xml).

          On the second screen you have the attribute collecting county - but repeated 50 times - and then use visibility to show/hide the one you want (which then has the correct xml for that state's counties).

          On the third screen you have your attribute for town (again the same attribute for each list) but this is where it gets a bit nasty at 50 times counties in a state.


          In terms of writing the required visibility rules you can probably leverage Excel to do a lot of the rule building for you from the lists (remembering that the compiler takes what you as the user see in Excel, not the function that Excel sees) - so there is not a lot of extra work from the rules perspective. 


          The biggest pain point will simply be putting all those attributes and linking up the right visibility attribute to the right control (and right xml).


          Proceed with (extreme!) caution but... if you're already automating creating the XML lists from Excel then you could consider automating creating the screen xml. But be very, very careful. I've seen some projects which have used automatically generated screens and they've made it work ok - but definitely a major health warning any time you don't use OPM to generate an OPM component.


          So... it is possible to do this manually - but you're probably going to want to get some automation involved.