Display Conditionals

Anne Rosebery
Form Developers, Platform Administrators
Knowledge of Javascript and how to build Kinetic Forms

The Kinetic Platform is a flexible tool used to create and maintain Business Solutions for a multitude of industries and applications. As such, there is often no one correct answer to architecture and development decisions made in the process of creating or maintaining said solutions. The answers to these decisions depend on many factors including current and future scale and growth potential, both of customer base and development staff, technical specifications for the solution, and more. To address the need to answer these questions that do not have a simple answer, we have created this Examining Best Practices series of articles.

This article examines how best to manage the display (show/hide) for the fields on forms.

Built in conditionals

The Kinetic Form builder allows for conditional display or validation of a field. This means that variables such as other field values, form attributes, whether the form is in review, etc can be used to determine if the field is to be displayed. This is evaluated automatically whenever there is a change on the submission to any of the values.

The benefits of using the built in conditionals are many: They are automatically evaluated without any need for custom javascript or events They are automatically evaluated on each and every change of the submission All criteria affecting display of that field is right there on that field and so is easy to find and check for validity if there are issues during development.

There are only a couple of potential drawbacks: In certain situations, you may find that you need an additional (generally hidden) field on your form to control the display of a section or field. Though there is nothing wrong with this, it can be something you may want to make design rules around where such fields go and what they are named, etc. These conditionals are part of the individual form. This means they are not part of shared code. This can be both good and bad. If there is shared behavior desired in a section, this can be done with a subform and still use the conditionals or, if you want to absolutely guarantee shared behavior, a file with javascript would be needed instead.

Shared Javascript Files

There may be times when you would want to leverage the javascript functionalities available to control display and validation of a field:

K('field[Field Name]').hide() 
K('field[Field Name]').show() 
K('field[Field Name]').disable()
K('field[Field Name]').enable()

This will allow you to control display of a field directly from the javascript, which does allow you to control display of a field by field name in shared javascript files. However, this may cause conflicts. For example, if you define a “Visible” condition in the builder of “Hidden” and then call the show method, eventually the form will self-correct and hide the field again. Leaving these conditions to their default state should allow you to use the functions in JavaScript event code.

This method also has the consideration of being difficult to troubleshoot. If you have fields displaying incorrectly, it can be difficult to track down the source for this in the javascript files that may be present on the server.

Given that the similar functionality could be acquired by having a particular field on those shared forms and setting that field to a value that, per the built in conditional, controls the display in the desired way, there is little to be said for this method unless it is something where the conditional is likely to be updated frequently. Then this method could prevent you from having to go into all the forms to update the conditional.