Revenge of the Dragon

I know what you're saying: "please, not more whining."  Well
rest assured that this isn't that kind of a post.  Yes, I ran into
some more problems with BD's compatibility with CFMX last night, but
I'm not bitter, I swear.  I took an app that I'd written for BD
and was moving it to CF7 this evening and found four distinct bugs in
BD that gave me grief.  It's worth mentioning that I'm running BD
6,2,0,226.2.28, which I believe to be a 6.2 release candidate, not the
final version, but I'm not 100% sure of that.

1) BD doesn't care if your 'var' declared local variables are at the top of a function or not, while CFMX does.

2) BD considers assignment to be an expression, while CFMX doesn't.  In BD <cfreturn s = s & "text" /> is legal.

BD processes CFLOGIN-based security stuff (at least when the
loginstorage is set to session) for all requests in a session that have
be logged in with CFLOGINUSER, regardless of whether CFLOGIN is
actually on every page.  In other words, on CFMX you have to have
CFLOGIN run on every page to use the cflogin framework, while on BD you
just have to have it run once per session.  Personally, I like
BD's interpretation, but all it takes is adding a self-closed CFLOGIN
tag right after your CFAPPLICATION tag to make it work on CFMX.

BD doesn't seem to validate return types on CFFUNCTION quite all the
way.  I had a function with a numeric returnttype that returned
the result of a SELECT MAX(...) ... query, and when no rows were found,
the result of the MAX call is obviously null, which isn't numeric (and
yes, I'm going to restrain myself from that rant ;).  BD happily
let me return null from the method, but CFMX errored.  Perhaps
because BD actually recognized the null for what it is, and let it pass
the test?

I also ran into
some issues using JS remoting (via Neuromancer) against a CFC-based web
service.  I had a lot of issues with getting that all working on
BD when I first wrote the app, so I suspect I ended up implementing
some stuff that wasn't quite CFMX-compatible, but I can't say that with
conviction, so I left it off the list of definite bugs.  The fix
was simple to make, so I'm not going to worry about it.

So there they are, four (and a half) points to watch out for when
moving from BD to CFMX.  As I said above, I'm not bitter, because
in every case the issue arose because I made an honest mistake in
coding, and BD did what I meant without
throwing an error.  Of course, in every case, BD was incompatible
with CFMX, but I'm going to put that behind me.  So if you're
developing on BD and planning to deploy to CFMX, watch out for these
gotchas.  Catching them as you code isn't a big deal, but having
to sweep an app for this type of stuff at deploy-time would be a bear,
especially if it's large.  The first two are compile-time errors,
so they'll be caught easily, the third will be apparent as soon as you
try to log in, but the fourth will require careful unit testing to
catch, because it's a data-dependant runtime bug.

5 responses to “Revenge of the Dragon”

  1. Calvin Ward

    Did you ever get all of your funding for a CF server?

  2. barry.b

    >> Perhaps because BD actually recognized the null for what it is, and let it pass the test?

    Barney, can you elaborate?

    I'm just starting to think that returning NULL for no data is a much better idea (esp for the numeric example you mentioned) than some arbitary sentinal value like "0″ or "-1″ or "".

    Sure, it can be worked around but only in context of what's required at the time (zero, empty string, throw an error). NULL still means "no data" and if CF could test for NULLs then I'm sure it might help.

    So how far does BD go with returning nulls?

    What would you like to see for CF?


  3. Barney


    Nope, sure didn't. I was moving an app to another CF server when I ran across the issues. The stuff will continue to run on BD, but it probably won't ever be updated again, as the CF7-compatible version is now the main branch.


    There was a long thread about this (and a few other things on CF-Talk a bit ago. You can hit the archives if you missed it. I don't believe that BD has any official support for nulls, but I suspect they might have some bugs in their implementation that exposes underlying machinery that does support nulls (since it's written in Java). So it's definitely buggy behaviour, but not necessarily undesirable behaviour, at least if it were documented and supported.

  4. Matt Liotta

    A quick read through your bugs in BD reads more like an enhancement list to me. Why would you not want BD to behave as it does in regard to your list? IMHO, CF should match BD in these cases.

  5. Barney


    Yes, in all cases, I think BD's behaviour to be more desirable, but that doesn't change the fact that CFMX is the definition of the CFML language, and so the discrepancies have to be deemed bugs in BD. At best they could be BD extensions, but to my knowledge, none of them are documented as language extensions. And in either case, they're incompatibilities between the two CFML runtimes, and that was really the point of my post.