{"id":91,"date":"2010-01-02T12:14:00","date_gmt":"2010-01-02T12:14:00","guid":{"rendered":"\/lisa\/post\/2010\/01\/02\/No-means-NO-but-so-could-almost-anything-else.aspx"},"modified":"2010-01-02T12:14:00","modified_gmt":"2010-01-02T12:14:00","slug":"no-means-no-but-so-could-almost-anything-else","status":"publish","type":"post","link":"https:\/\/spacefold.com\/lisa\/2010\/01\/02\/no-means-no-but-so-could-almost-anything-else\/","title":{"rendered":"No means NO — but so could almost anything else"},"content":{"rendered":"

\nDecember just flew by.\n<\/p>\n

\nI last wrote at Thanksgiving.  Here it is January, a new year, and I'm still missing Kami<\/a> and wondering why she's not visible.\n<\/p>\n

\nI'm sure she's ignoring me<\/strong>, wherever she is.  I just miss watching her do it. I guess we'll just have to get on with it.  And maybe I'll take the occasion to discuss a topic that has often plagued me in integration work, not just with regard to cats.\n<\/p>\n\n\n\n
\"Kami<\/td>\n\n

A question of empty-ness and absence<\/h3>\n

\n\t\t\t \n\t\t\t<\/p>\n

\n\t\t\tIn working with Linda a couple of months ago, to figure out how to stop data from appearing when you don't want it<\/a>, I found I needed to have just such a discussion: How does the evaluating code know when you want to do this?\n\t\t\t<\/p>\n

\n\t\t\tUsually it comes down to figuring out some sort of negative condition.  When the users haven't provided parameter values yet, the code should realize this and not do any unnecessary work. \n\t\t\t<\/p>\n

\n\t\t\tReporting Services has a default way to deal with this; you omit a default value for a parameter, and you don't allow nulls for this parameter.  The user is required to fill in that value before the work continues.  However, the default UI for this is not pleasing to many people.\n\t\t\t<\/p>\n

\n\t\t\tIn this scenario, and in many integration scenarios that have nothing to do with reporting, you can be moving between environments that don't understand "null", "nil", "nothing", "blank", or even a straightforward boolean "false" exactly the same way.  You have to find some way that the receiver can understand a boolean false, a blank, or an absence of viable content, as provided by the sender.\n\t\t\t<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

\nJust now, I started to write that this is the most annoying type casting and massaging scenario I know about — but.  Don't get me started on dates and date times. Let's stick to one annoyance at a time.\n<\/p>\n

\nSo…  \n<\/p>\n

What's an appropriate strategy?<\/h3>\n

\nUsually I find two things have to be considered if I want my code to work with multiple calling environments:\n<\/p>\n

\n1- The receiving environment has to define the values it considers to be a boolean false and\/or a boolean true for a string according to the senders it expects.  And it has to define these generously, and widely, not according to its own ideas (so, no, the default behavior of Boolean.TryParse isn't good enough, thank you very much). \n<\/p>\n

\n2 – The receiving environment has to figure out what it considers blank and what it will do with values that evaluate to null-or-empty.  And here, as well, the receiving environment can publish its limitations and stick to its guns, but if it wants to have a usable and popular interface, it should bend over backwards to consider other people's ideas of proper input values, and offer some reasonable amount of choice (so, no, the default behavior of String.IsNullOrEmpty isn't good enough, either, thank you very much).\n<\/p>\n

How do you carry it out?<\/h3>\n

\nBelow is an example, in VB.Net, of how you can allow the caller to specify what "empty" content should look like, in various ways:\n<\/p>\n