What is the best way to populate a dropdown ?

I need the managers list while adding an employee . i have an employee and manager table . 

while creating an employee , i need to populate managers list so that HR can assign the manager to an employee . in the interface i need to populate the Manager dropdown .

 

Option 1 

 

--Create a query entity to fetch all the managers 

--get the data subset 

-- initialize local!managers:rule!getManagers()

and display like below  

a!dropdownField(
label: "Manager",
labelPosition: "ADJACENT",
placeholderLabel: "--- Select a Manager ---",
choiceLabels:{index(local!managers.data,"name")},
choiceValues:{index(local!managers.data,"name")},
value: ri!manager.name,
saveInto: ri!manager.id,
validations: {}
)

 

are there any better approach ?

  Discussion posts and replies are publicly visible

Parents
  • 0
    Certified Lead Developer

    Your snippet should look more like

     

    a!dropdownField(
        label: "Manager",
        labelPosition: "ADJACENT",
        placeholderLabel: "--- Select a Manager ---",
        choiceLabels:{index(local!managers.data, "name", {})},
        choiceValues:{index(local!managers.data, "id", {})},
        value: index(ri!manager, "id", null),
        saveInto: ri!manager.id,
        validations: {}
    )

     

    If your query doesn't take too much time, loading the managers in a load() variable on the interface will be fine. However, this load variable will re-evaluate whenever the user opens up the interface, so if you anticipate both the user frequently leaving/coming back to the form AND the query is slow, I would store the data in process and pass the list in as a rule input.

  • > I would store the data in process and pass the list in as a rule input.

    Is it a good practice to keep long lists in process variables? It will consume Appian memory. Practically I don't think there would be a very long manager list. In case it is it would be easier to select department first with less managers inside.
  • 0
    Certified Lead Developer
    in reply to sergeiz
    The exact approach depends on the use case. The recommendation was made to improve user experience if the query to retrieve the managers was slow.
  • I don't think extracting two columns for 1000 records will take much longer than for 10. If everything is OK on the database side, not a heavy view, etc.

    And if the size of the data is an issue it is not good to cache it in each process.
  • 0
    Certified Lead Developer
    in reply to sergeiz
    Again, the exact approach depends on the use case. While I generally agree there would not be a difference between querying 10 records vs. 1000, this is not a guarantee.

    The same goes for caching data in process, there is a trade-off here between process memory and user experience. You can easily reduce process memory by marking the process variable as hidden and update your archive settings to quickly archive the process.
Reply
  • 0
    Certified Lead Developer
    in reply to sergeiz
    Again, the exact approach depends on the use case. While I generally agree there would not be a difference between querying 10 records vs. 1000, this is not a guarantee.

    The same goes for caching data in process, there is a trade-off here between process memory and user experience. You can easily reduce process memory by marking the process variable as hidden and update your archive settings to quickly archive the process.
Children