List of Required Fields

Hi,

Looking for the best way to create a list of required fields on a page.

Would we use the “is disabled” feature on the save button for the page, with conditions such as
If(input1) = NULL AND if(input2) = NULL.

Or would there be a better way? The forms contain about 50 variables each but not all are required.

Thanks!

Hi!

You’ve figured out the crux of it! Using the “is disabled” feature under those conditions is absolutely a valid way to approach this problem, and if the form only contained 2 or 3 variables, I imagine we’d be content calling this the “best” way forward.

But you’re right – 50 variables seems like an awful lot to check that way. From here on out, the “best” way strikes me as a matter of personal preference. Here’s how I might go about it:

The “is disabled” feature disables the button when given input that evaluates to TRUE, so I want to deal with a lot of the logic behind that by making a UDF that evaluates to TRUE if any of the values it checks is NULL. It’ll take input in the form of a List, which I’ll call test_list, and the UDF will look as follows:

CONTAINS(
  FROM
    item
  IN
   test_list
  SELECT
    ISEMPTY(item),
  TRUE
)

This uses the cycles through each item in the List and checks if it’s empty. If any of the items are, it will return TRUE; otherwise, FALSE.

I can then call on this UDF (call it UDF for example purposes) in the “is disabled” feature, and feed it a list generated from the variables I want to require. In your simple example, when these variables consist only of input1 and input2, it would look like this:

UDF([input1, input2])

That List gets longer and more cumbersome to write the more fields you want to require, but at least you don’t have to write out “ = NULL” as many times.

Is this truly better? I don’t know! It might run a little slower, but in a way that’s probably pretty negligible. Does it save you time writing out Airscript expressions and make things easier to conceptualize? I would say yes, but the margin isn’t as wide as I would prefer. On the plus side, the UDF can be reused, so if you have a multi-page form, it might save time repeatedly.

Does that help? I’m curious if anyone else has any other ideas for ways that might be considered “better” in cases like this!

1 Like

Thanks!

Would there also be a way to have different conditions on which fields are required? We have many questions that are conditional based on preview answers.

It’s always possible to have different conditions on which fields are required! We just run into that problem of the “best” way to do it being debatable again.

The simplest way I can imagine for handling something like this would be to implement that earlier solution, and then run some conditionals while generating the List that’s given to the UDF.

So say we have a form with three inputs: input1, input2, and input3. input1 and input2 are always required, but input3 is only required if input1=100. We can call on the UDF created above as follows:

UDF(
  [
    input1,
    input2,
    IF(
      input1 = 100,
      input3,
      "not required"
    )
  ]
)

This uses the IF function to check if input1 is equal to 100. If that is the case, it returns input3, and the UDF will check if input3 is NULL, same as all the other input values it’s given. If that isn’t the case, it returns the string “not required” - a value that’s only important because it’s not NULL, and therefore won’t be considered an empty value by the UDF.

This seems like a straightforward way to do this. But of course, it can always get more complicated.

So say we have a form of four inputs: input1, input2, input3, and input4. input1 and input2 are always required, but input3 and input4 are only required if input1=100. We can do the exact same thing we did above and run the check twice:

UDF(
  [
    input1,
    input2,
    IF(
      input1 = 100,
      input3,
      "not required"
    ),
    IF(
      input1 = 100,
      input4,
      "not required"
    )
  ]
)

but if we have to do this too often, we’re once again back to the original problem, which is that the associated Airscript expression is extremely long and clunky.

To help lessen that problem, we can run the check only once and have it return a List of all the input required if the condition is met. Then we can use the FLAT function to “flatten” the List potentially returned by the IF function into the broader List we’re giving to the UDF:

UDF(
  FLAT(
    [
      input1,
      input2,
      IF(
        input1 = 100,
        [ input3, input4 ],
        "not required"
      )
    ]
  )
)

Once again, I don’t know if that’s actually better! It seems like it could be less cumbersome to write, and if you’re dealing with 50+ variables on a form, that seems potentially worth it? There might also be ways to make some of the conditionals themselves UDFs to help them scale, depending on the details of how the variables relate to each other.

What do you think? Does that help, or do the additional layers of abstraction just make things harder to debug?

With the “is disabled” box, does the logic have to be one string with AND/OR statements, or can it use many conditions separated by commas?

It doesn’t recognize commas in that context, no. Airscript expressions need to be separated by AND/OR statements, and each of those Airscript expressions need to ultimately evaluate to a Boolean.