Dropdown field configuration

Hi Experts,

I have a requirement where I need to configure gridLayout in such a way that I can add rows maximum to number of data I have in a local variable, i.e if value in localVariable is {"ABC","DEF","GHI","JKL"} the only 4 row can be added at max.

Grid needs to have 2 columns where first column will display the value in a dropdown field, the value once selected in the row should not appear in the next row, i.e if value stored in localVariable is: {"ABC","DEF","GHI","JKL"}, we should be able to select any of the four value in the dropdown of the first row, in next row we should only be able to select from the remaining three options and so on

On the same time the second column will display the data in dropdown, value being dependent on the value selected in first column of the same row.

Need your suggestion on the above configuration.

  Discussion posts and replies are publicly visible

  • Hi, here's a sample grid to get us going.  This should satisfy your requirements, with the exception of modifying the second column to handle whatever you need for the that dropdown for local!rows[fv!index].col2 based on local!rows[fv!index].col1.  This allows a maximum of rows added to match the options list, and removes values from the dropdowns as they are selected in other rows.  

    a!localVariables(
      local!options: {"ABC","DEF","GHI","JKL"},
      local!rows,
      
      a!gridLayout(
        headerCells: {
          a!gridLayoutHeaderCell(label: "Column 1"),
          a!gridLayoutHeaderCell(label: "Column 2"),
        },
        rows: {
          a!forEach(
            items: local!rows,
            expression: a!gridRowLayout(
              id: fv!index,
              contents: {
                a!localVariables(
                  local!ddlOptions: reject(
                    fn!isnull,
                    append(
                      difference(
                        local!options,
                        a!forEach(
                          items: local!rows.col1,
                          expression: tostring(fv!item)
                        )
                      ),
                      local!rows[fv!index].col1
                    )
                  ),
                  a!dropdownField(
                    placeholder: "-- Select --",
                    choiceLabels: local!ddlOptions,
                    choiceValues: local!ddlOptions,
                    value: fv!item.col1,
                    saveInto: local!rows[fv!index].col1
                  )
                ),
                a!textField(
                  readOnly: true,
                  value: fv!item.col1
                )
              }
            )
          )
        },
        addRowLink: a!dynamicLink(
          showWhen: count(local!rows)<count(local!options),
          label: "Add a Row",
          saveInto: a!save(local!rows,append(local!rows,{col1: null, col2: null}))
        )
      )
    )

  • 0
    A Score Level 2
    in reply to Chris

    Thanks Chris

    This has helped me Slight smile

  • Hello Chris (and anyone else who would like to comment),

    I am working with a trial version of Appian and so far really like the product and the community.

    First, I would like to say this is a really great and active community.  It makes you want to be part of it.

    Regarding this particular issue and coming from a Windows Client application mentality, I would generally populate List B based on an SQL call using arguments from List A.

    So I am wondering how different is the paradigm in THINKING about the architecture?  What should I be throwing into the trash heap with a new way of approaching business process oriented applications?  What should I embrace?  What fundamental changes in thinking are suggested in order to succeed?

    Thanks in advance for your thoughts!!

    Paul

  • Hi Paul, welcome aboard!  

    To note, there is a wealth of excellent documentation available including samples, best practices, component functionality, available functions, etc.  If you haven't become familiar yet, I would definitely recommend doing so!  My favorite area is the Interface Patterns.

    In regards to the situation in this thread, you can certainly populate List B based on a call to the database via a!queryEntity(), relative to the selection in List A.  I have a number of applications which use that type of setup.  There are also some cases, depending on data sets, where you may pre-set List B options from the DB into a local variable on form load, then pull specific values from the local var for List B depending on List A (better for performance, in some situations).

    For changes in your thought process, I can't really see anything major that would be 'trash' per say as far as logical application design goes - except maybe thinking you still have to build everything from scratch Slight smile

    Build a few small processes, become familiar with the components and functions, keep tabs on the forum and documentation and you'll be good to go!