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.
Comments are closed.