Frequently we need to be able to mandate that a field is completed before a record can be saved. In this post, as the title perhaps eludes to, we are going to discuss essentially three methods of mandating user input (plus a variation on the third). We will look at the pros and cons where applicable and give examples of how to implement these methods. Hope you enjoy.
“Belt and Braces” – “Not Null”
So the first method we are going to look at is what I call the belt and braces method – using the database administration tool we can specify that the field cannot contain nulls as shown below:
Not null field
As you might expect with any belt and braces method this method has some serious pros and cons. On the pro side, this is the only method that also works if data is being added/updated in the database using an external method e.g. the Integration Engine or SQL Scripts. On the downside, this is about as inflexible as you can get. If you decide that actually there could a circumstance where it could be null then you need to take down the system and remove the null constraint using db admin. The other issue with using this method the error message returned is not really customisable and tends to be a bit, how does one say, unfriendly.
Error message if Not Null field is not placed on form
Error message if Not Null field IS placed on form
Where this method really scores is, for example, in many to many relationship tables and/or foreign key columns where the child records must have a parent e.g. Incident Details Incident # field etc.
“The Old Way” – “Required If On Form”
Back in the days of Magic 7.5 CSBRs didn’t exist and so if you didn’t want to force the column not to accept nulls then the only other choice you had was, again using db admin, to specify that a field was “Required if on form” as shown below:
Required if on form field
Here the advantage is when you add said field to a form, the application will automatically require that it is filled in. If it is not added then it won’t cause you any issues. It doesn’t enforce database integrity in the same way as the not null above which gives you a bit more flexibility but has its drawbacks as well. The big disadvantage is precisely what it says on the tin – if it is on the form then it is required. So you can’t have two forms, both with the field on it, but on one form the field is required and on the other it isn’t. Personally, I don’t make use of this method anymore as I think it has been superseeded by the flexibility of CSBRs.
“The New Way” – “Client Side Business Rules”
Since Magic 7.52 we have had a new toy to play with – the Client-Side Business Rule (CSBR). The CSBR essentially allows the Administrator a GUI to build JavaScript functions that can do a whole bunch of functions. One of the functions it can achieve is that of mandating user input. Below is a simple example of a CSBR to mandate that an incident cannot be saved if the Incident Description field is not populated:
The massive advantage you get with CSBRs is flexibility. CSBRs can be added (or removed for that matter) without any need to take down the system; can be applied to certain forms and not others allowing the mandating of user input on one form but allowing nulls on another; allow Administrators to create friendly (or not so friendly) error messages; and allow for complex rules such that if field (a) and field (b) are blank popup a message. The disadvantages are largely that a) you actually have to build CSBRs to do this functionality and b) adding too many CSBRs to forms can cause issues of CSBRs not firing or producing unexpected results.
A slightly different approach
Personally, I use a combination of Not Null and CSBRs. However, if you were to follow the approach I detailed above for the use of CSBRs you could end up with a massive number of CSBRs for a single form (if you had a lot of mandatory fields). As such, I make use of a slightly different approach where I create a single CSBR called Mandatory Fields in each module as follows:
The key to this approach lies in how you design the form. I try, within the confines of the application, to make use of standard usability techniques – namely the use of asterisks to mark mandatory fields as shown below:
Usability Incident Form
Summary
So all techniques have their place – their advantages and disadvantages which I hope I have given you a feel of. As always, your feedback (positive and negative) is always welcome.
JOATIT 