Coldbox and VueJS untangled

Input validation with full null support

Adobe introduced full null support in ColdFusion 2018. Before 2018 null values returned by databases and external systems were converted to empty strings. This behaviour made it almost impossible to distinguish between empty strings and null values, and also caused issues with serialization and deserialization. You also had to take special precautions to insert or update null values in a database. Interaction with Java, including CFORM based hibernate could also result in returned null values so we always had te be very careful when trying to handle these dreaded nulls.

Lucee already has full null support since many years, but just as with the latest ACF version, you have to enable this in the administrator, just to stay compatible with older versions of ACF.

So, because of all these null handling issues, why not enable full null support? That’s what we imagined when creating our latest REST based application. But before hurrying to your admin panel better think if it will break something.

Before the Modernize or die times as promoted by Ortus Solutions there were many ways to find out in Coldbox if all input variables existed. Let me give these two JSON examples, both are used for the creation of a user in the body of a post request:

//first example, customer_id as a null value because customer is not selected yet
{
    "customer_id": null,
    "username": "wdb",
    "password": "topsecret"
}
//second example, customer_id omitted because customer is not selected yet
{
    "username": "wdb",
    "password": "topsecret"
}

When we post this userdata, I want to validate if my customer_id is there so I can populate some required customer field. When null support is not enabled we have a few options to check if we have a usable customer_id.

function createUser( event, rc, prc ) {
  //option 1
  if ( event.valueExists("customer_id") ){
    //....
  }
  //option 2
  if ( structKeyExists(rc,"customer_id") ){
    //....
  }
  //option 3
  if ( !isNull(rc.customer_id) ){
    //....
  }

The first options seems to make sense. Event.valueExists is a way to check if my customer_id is a value in my request collection.
The second options is slightly more low level, it just checks the request collection for the existence of customer_id.
The third option is a little bit more direct. It just checks if rc.customer_id is not null so I can continue.

So it seems it doesn’t matter which method I use. But now I enable full null support, and the whole landscape is changing. In the previous part I just assumed the key should be there, or not be null.

But now I have to know what my frontEnd VueJS developer is doing. Is he sending a null value for customer_id if there is no customer selection yet? Or is he only sending values in the JSON body which already have a value? This will make a lot of difference .

If my frondend developer is sending null values and I enable null support in CFML my event.valueExists and StructKeyExists() checks are completely useless, because my customer_id variable now does exist in the request collection. The problem here is it’s value is useless, because I can’t retrieve a required customer based on a null value. So the only safe check now is the !Isnull(rc.customer_id) .

The situation is still a bit different if you also want to be able to update a database based on the input of a null value. In that case you have to check for both Event.ValueExists AND IsNull.

The above examples seem quite trivial, but a word of warning is appropriate here. You really have to know how your frontend application should handle these null values. Are you validating ALL properties, or only the properties which have been entered by the user?

A second important point is the handling of nulls in some of your supporting libraries. We failed a lot of tests because one of our libraries tried to determine the datatype of our input automatically. Since null values have no datatype the library failed. This was fixed very soon, but especially when using some older libraries or modules you really should take a close look at the code when possible.

1 Comment

  1. Ben Nadel

    Thanks for the perspective. I’m considering enabling full null support on my blog, if for no other reason than to keep with all the modern practices. But, like you’re saying, my app is full of `.keyExists()` calls for null checks. Before I turn anything on, I’ll have to be sure to do a bunch of experimentation to get a sense of where the edge-cases like this are. I am kind of excited, though – null feels like one of the _last places_ where ColdFusion is behind other languages.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

© 2022 ShiftInsert.nl

Theme by Anders NorenUp ↑