BarneyBlog

Couple more little glitches as the app has continued to be tested:

1)
I mistyped 'reqeustTimeout' [sic] in a CFSETTING tag.  BD didn't
complain, and I didn't catch it, because the extra time for the request
never happened to be needed, but CF threw a syntax error immediately.

2)
BD 6.2 puts the CFFILE result struct from uploads into local variable
(if declared), inside functions. I was never quite sure what CFMX 6 did
regarding this.  CF7, however, puts it in some unknown place
(presumably variables scope) that is shadowed by the local variable
scope.  Just a matter of adding the new CF7 'result' attribute to
name the value you want the result placed in.  I think this is
actually a bug in CF7 (breaking backwards compatibility), but I'm not
sure about that.  Either way, it is a difference between BD and CF
that you should watch out for.

Vince from NA just provided some clarification on the 6.2 release and
RC expiration on the BD mailing list.  BD.NET is the only edition
that is set to expire on the 31st, and it doesn't expire, it just
reverts to developer edition.  The Java editions don't expire
based on dates, they expire based on the trial licenses (never for
free, 30 days for JX, and based on the eval license for the J2EE
edition).  So unless you're running BD.NET, the March 31st
deadline isn't a concern.

Of course, after the final 6.2 release, NA is dropping all support for
the RC, so you're better off upgrading sooner than later, but there
isn't the hard deadline to do so.

BlueDragon continues to give me fits. CFEXECUTE (which I'm not sure - there is conflicting evidence - is supported on the Server edition) refuses to work correctly. No big deal, since launching a Process direct from the Runtime class is straightforward (I didn't need the IO streams, in this case). However, the waitFor() method of Process refuses to do anything except throw exceptions when called, which basically means no syncronized subprocesses. So what's the solution? Write a JSP page that does the exact same thing (except it works) and then call it with CFHTTP. Hardly elegant, but it worked well enough.

Next problem was doing some simple image manipulation with the ImageIO class (from javax.imageio). Nothing complex, just a simple read-scale-write operation to generate a thumbnail. However, BD pukes on the write part. From the stack trace on the NPE, it appeared that it was having trouble selecting which of the method versions (write is overloaded) to call, even though it was pretty clear cut (the one with a RenderedImage, a String, and a File). What's the solution for this case? You guessed it. Write a JSP page that does the exact same thing (except it works), and then call it with CFHTTP. Ooof.

I do tire of such hacks, and so once again, my pursuit of the CF license is in full swing. I just finished up some more work for Fusium (awaiting the check), and lined up another little project that should just about round out the two grand I need. Now if only I could be done and have the license today….

So, BD 6.1 Beta solved most of my problems with CFCs. I'm on cloud nine, and I'm finally getting some work done. It's not perfect, but none of the other bugs were really more than inconveniences (for instance, it gets grumpy when you mix full CFC paths with pathless references to CFCs in the same package). No big deal, just figure out what the issue is, and work around it (always full-path everything, in this case). Plugging away, and I've got the backend of my app finally put together.

Now it's time for the front end. Throw the Fusebox 4.1 skeleton app in there and run it. Error about indexing 'attributes' as an array, trying to set the default fuseaction. Refresh. No issue. WTF? Refresh, fine. Refresh, fine. Touch the code, refresh, error. An hour later I've isolated the problem. Scope leak on a CFLOOP tag iterating over a query.

We all love the fact that CFML lets you reference the fields of the current record of a recordset you're looping over with just the column name. Once you stop the loop, that stops functioning, and you have to again fully scope the field you want (queryname.columnname[row]). BD was doing that, but if you raised an exception inside the loop, it never bothered to turn off that special psuedo-scope. Which meant that for the remainder of your request, variables in the VARIABLES scope that happen to have the same name as a column in the query you were iterating over are shadowed, just as they were inside the CFLOOP.

And of course, 'attributes', that wonderfully versatile, utterly indispensible Fusebox scope is the problem in this case. The loader runs a CFDIRECTORY tag and loops the result, potentially throwing an exception. And guess what, there's a column called "attributes" on queries returned from CFDIRECTORY, so any time it throws that exception, the request fails. (As an aside, the exception in question is an internal exception that the core files use for their internal functioning. It never sees the light of day, except in the CFMX debugging output, if you have the exception list turned on.)

Fortunately, that exception will never be raised in production environments, it's part of a development-mode-only feature (the conditional loader), so no apps are going to break. But it makes development rather difficult, as you might imagine.