You are viewing limited content. For full access, please sign in.

Discussion

Discussion

Enhancement Idea: Field Rules Applied to All Fields of a Type or with a Class

posted on March 25

I just encountered a situation in the Layout Designer where I would use Field Rules, but it'll need to apply to hundreds of fields, so I'm using Javascript instead.

The fields I want to target need a CSS Class added to them under certain circumstances, so the new expanded Field Rules would be my go-to.  However, there are so many of the fields, and I want to keep it as easy as possible to add/modify these fields in the future, so it is kind of daunting to use the Field Rules in this case.  It would be a single Field Rule, but would be targeting hundreds of fields.

I decided in this case to use Javascript triggered via changes to the fields to check if they meet the criteria and add or remove the CSS Class as needed.  This is working, so it is a valid solution.  In this case I am targeting the fields based on another CSS Class that every one of these fields will include.

But it occurs to me that it would be helpful if I could have had the Field Rule target all the fields by criteria instead of selecting each individual field.  In this case, the target criteria would be "All fields that have xxx class", but I can certainly see cases where some other options would be useful, such as: "all fields" or "all fields of xxx type" or "all fields where label contains xxx" or "all fields within xxx section" (we can target the section itself for some rules like show/hide/validate, but others like add class would apply to the section not the fields within it).  This would be similar to how the custom Error Message rules can target larger groups of fields, it would be nice for Field Rules to be able to do that too.

Forms Version 12.0.2509.20409

6 0
You are not allowed to reply in this post.
replied on March 25 • Show version history

Well well well, I was wondering when someone would run into this issue and report it. We discussed this at length when we added the feature way back when. It really is a catch 22, we could give you the ability to rerun JS but it would then cause other adverse affects like rerunning business logic that has already run. You'd end up trying to fix edge cases that would never show up in a live process.

Another option was using url parameters to set the step/stage, but this would conflict with filling form fields and had potential breaking changes to the millions of ways people use forms.

The final option was preserving step/stage on refresh, but we were afraid people would get confused that the form looks different when loading a new preview.

There really isn't a workaround outside of testing in the actual process (not preview). Although you could bundle each page's business logic into functions and rerun those manually either through the dev console or through a window function.

 

I am open to ideas though. What was the exact issue you had? Was it code just not running when the step wasn't defined? You could add the isPreview flag to your condition so the code always runs.

replied on March 25

Hey @████████- I think you meant that reply for this other post instead:

https://answers.laserfiche.com/questions/235961/Form-Preview-May-Not-be-able-to-Test-StepStage-Specific-Javascript#repliestomain

You are not allowed to follow up in this post.

Sign in to reply to this post.