choose function usage with rule inputs as parameters.

Question

Hello, mates! 
 I would like to create a rule that will provide choices/options through parameters to be used with the choose() function ( https://docs.appian.com/suite/help/25.1/fnc_logical_choose.html ) 
 However, the choices will not have a default length. I tried using Appian array, but as expected, it didn't work because choose() expects individual parameters, not an array. 
 
 I'm working on creating a tab interface component, where the number of tabs isn't fixed, hence the need for dynamic choices. 
 Does anyone have any hint on this? Thanks.

Harsha Sharma · Accepted Answer

You need to figure out at most how many tabs can be there when either all conditions are passed or none applied. 
 If you can have at most 7 tabs then your match() needs to be configured with all 7 possibilities. Assign one unique index to each tab so that if dynamically only 4 tabs (e.g. Tabs 1,3,4 and 7) are selected, the indexes replicate the same. 
 
 If it easier you can also go with strings to match the selected tab with content instead of index. a!localVariables(
 local!selectedTab: "Tab2",
 a!match(
 value: local!selectedTab,
 equals: "Tab1",
 then: a!stampField(
 labelPosition: "COLLAPSED",
 icon: "angle-down",
 contentColor: "STANDARD"
 ),
 equals: "Tab2",
 then: a!stampField(
 labelPosition: "COLLAPSED",
 icon: "angle-up",
 contentColor: "STANDARD"
 ),
 equals: "Tab3",
 then: a!stampField(
 labelPosition: "COLLAPSED",
 icon: "angle-double-up",
 contentColor: "STANDARD",
 backgroundColor: "NEGATIVE"
 ),
 default: "No Priority"
 )
)

Mike Schmitt · Answer

Either way you'll need to figure out a way to work within the system's constraints - mainly here that there isn't a supported way to call arbitrarily-named sub-interfaces (or other rules etc); whatever you want to use will need to be hardcoded into the parent interface. You'll have a lot better time if you architect it in such a way that you can use a limited set of sub-interfaces and parameterize the contents using tab-specific data you pass in (as needed).

Mike Schmitt · Answer

Don't use choose() at all now. For anything. We have a!match() now.

Mike Schmitt · Answer

It works with anything you want. I'd be happy to help you through a realistic example if you want, but you'll need to provide some sample code / sample data / screenshots / etc, just something more than a vague description.

Mike Schmitt · Answer

If you're calling different sub-interfaces, then of course they'll need to be declared directly in the code for your parent interface. I'm still a little shaky as to what your overall configuration looks like, but i'm guessing you can configure something along these lines: 
 a!match(
 value: local!selectedTabIndex,
 
 equals: 1,
 then: rule!BBB_TAG_1(...),
 
 equals: 2,
 then: rule!BBB_TAG_2(...),
 
 [... etc],
 
 default: rule!default_tab() /* use for default or invalid selection, etc */
)

Mike Schmitt · Answer

Silas. B. Ferreira said: The issue is that the length should be dynamic, through parameters 
 How do you plan to handle a dynamic length of tabs with a prescribed set of sub-interfaces? There isn't a way to dynamically generate (named) interfaces.

Mike Schmitt · Answer

Just as you would need to manually create all rules rule!APP_content_ X () for X = 1.... n , you would need to hardcode them into your calling interface in some way or another. 
 a!match() provides far greater flexibility than choose() in that you don't strictly need an array of strictly n parameters passed into it, but can instead handle anything up to and including n . But it doesn't, per se, buy you the ability to avoid hardcoding interface names that you need to call. 
 (But you might want to look at making all or some of these interfaces programmatic, meaning they share the same interface but act differently depending on a parameter you pass in - if possible, which of course I can't say for sure since I don't know how different they all need to be.)

Silas. B. Ferreira · Answer

I see, thank you and Harsha as well. I guess I will just componentize the tabs, and use a rule input to store the index back to the whichever main interface use the component, that should work like: /*ri!tabs: (Array of Text)*/
/*ri!activeTab: (Integer store the active tab through index)*/

a!localVariables(
 a!cardLayout(
 contents: {
 a!cardLayout(
 contents: {
 a!columnsLayout(
 columns: {
 a!forEach(
 ri!tabs,
 a!columnLayout(
 contents: {
 a!cardLayout(
 contents: {
 a!richTextDisplayField(
 labelPosition: "COLLAPSED",
 value: {
 char(10),
 a!richTextItem(
 text: ri!tabs[fv!index],
 color: if(
 fv!index = ri!activeTab,
 "STANDARD",
 "ACCENT"
 ),
 size: "STANDARD",
 style: if(fv!index = ri!activeTab, "STRONG", "PLAIN")
 ),
 " ",
 a!richTextIcon(
 icon: "exclamation-triangle",
 showWhen: false,
 color: "NEGATIVE"
 )
 },
 align: "CENTER"
 ),
 a!cardLayout(
 style: if(fv!index = ri!activeTab, "ACCENT", "NONE"),
 padding: "EVEN_LESS",
 showBorder: false
 )
 },
 link: a!dynamicLink(value: fv!index, saveInto: ri!activeTab),
 padding: "NONE",
 showBorder: false,
 accessibilityText: if(
 fv!index = ri!activeTab,
 "Selected Tab.",
 "Unselected Tab. Press enter to select tab."
 )
 )
 },
 width: "NARROW"
 )
 )
 },
 marginBelow: "NONE",
 spacing: "NONE"
 ),
 a!cardLayout(padding: "NONE")
 },
 padding: "NONE",
 showBorder: false
 ),
 
 },
 padding: "NONE",
 showBorder: false
 )
)

choose function usage with rule inputs as parameters.

Top Replies