Hi Patrick,
Your suggested condition has the same issue. Here’s my revision:
return (val == null || val === '') ? def : val;
I added a triple equal check on the 2nd condition to check the type as well, because otherwise 0 == '' would be true
The 1st condition is ok to have a double equal check, to account for both null and undefined
This could be a HUGE breaking change given that people will have built using the existing behaviour where 0 is returned by functions, formatters, queries etc…
Could you add a checkbox that adds a second parameter to allow zero values so it would become:
somevalue.default(null,true)
If the second parameter was missing/false the existing behaviour would be used. This should prevent existing projects from breaking
Do you really think that there are cases that users expect a 0 or false to be handled by the default formatter as not having a value. The default formatter is mostly used on data posted from forms to set a default value when the form field wasn’t set. This is always and empty string or if the field is missing from the posted data it is undefined.
The description for the default value is:
Sets the default value if binding has no value
Having it setting the default value on 0 or false is not what it is meant to do. We could have a discussion about if it should apply the default when the value is an empty string, since in programming languages it means it has a value but in case of a form submit it is an empty value. In App Connect we do not set the default on empty string, only when the value is null or undefined. I added the empty string as exception to not break existing projects.
I’ll leave the discussion open here and not making this change right now. There are a lot of requests here in the forum that we should update the formatters in Server Connect to have them have the same behavior as the ones in App Connect. Several formatters are missing or they work different on the server, we can add missing formatters without any problems, but when updating existing formatters it can have some breaking changes, especially when the arguments order changes as with the where formatter which is on the client has (prop, value, operator) and on the server (prop, operator, value).
Unfortunately it doesn’t matter what the description says, people (including myself) have been using it with its current behaviour for years. It is probably the most common formatter I use and am pretty sure there have been cases where 0/false expectation is part of the logic. It may be not often but trying to find those needles in the enormous haystack of multiple projects each with many, many server connect files is not an option for me.
Thanks for all the responses to this and apologies for my delayed response.
I ended up approaching this from a different angle using the validator to prevent null submissions - I don’t actually want nulls in the final dataset but I’m dealing with historical data that includes a load of nulls so I originally built the update form to accommodate these and allow the user to leave null entries if they wanted (i.e. not answer the question until a later date), hence the <option></option> in the select field (I don’t want these selects to default to yes or no so need a blank option). The validator means the user will have to fix all the nulls before they submit the form which is probably ok although I may look at @bpj suggestion $_POST.somevalue === '0' ? 0 : $_POST.somevalue.default(null) which seems like it should work…if users start complaining.
Thanks again!
I’ve checked the default formatter in all server models. It seems that NodeJS, ASP and ASP.NET all return the default when the value is falsely, so a 0 value would return the default. In PHP it returns the default then the value is not set (null,undefined) or empty ("",[]) but not for a 0 value. Client-side App Connect only returns default when value is null or undefined. Seem’s that they all behave just a little different while it should all do the same.