G'day:
Just before I start, I would like to vent some frustration.
I am working on a side project after-hours, only getting a chance to
work on it for a few hours on the weekend, and the odd evening after
work such as now. One of the original requirements of this project is
that it must work in CF8 & OBD. In the last three sittings that I
have had - about six hours all up, I guess - I have only managed to
move forward with my own work by about 15 lines of code. All the rest
of the time has been taken up puzzling over bugs in OBD, replicating
them, and logging them (well: blathering on about them on this forum,
anyhow ;-). I am now very very hesitant about whether I think OBD is
production-ready, to be frank. It's not like I'm going out of my way
to find these things, and it's also not like they're particularly
esoteric edge cases either. All I'm currently doing in this project
is writing unit tests, after all: not complicated stuff.
I have now recommended to my client that we shelve the idea of OBD,
and I'll perhaps be looking @ Railo instead. Or for heaven's sake
can't they just stick with CF! [grumble].
I'm not cross or anything, and I don't at all mean to take away from
your hard work on this project, because it's certainly very impressive
what you have achieved, and on the whole I've found my time on this
forum an OK experience, and you've helped me a lot. And for that I am
very grateful. I just think it might be useful for me to share my
experience and... um... "standpoint", I guess, as well as bringing the
bugs to your attention.
And now for the bugs.
Today I found one bug, and then whilst contriving the test case for
it, found another one.
First. The bug in <cfreturn> / <cfoutput>
Consider this code:
<!--- ReturnInQueryLoop.cfc --->
<cfcomponent>
<cffunction name="f">
<cfargument name="id">
<cfscript>
var aDebug = arrayNew(1);
var q = queryNew("");
var b = false;
arrayAppend(aDebug, "Initalised");
queryAddColumn(q, "id", listToArray("1,2,3"));
queryAddColumn(q, "data", listToArray("one,two,three"));
arrayAppend(aDebug, q);
</cfscript>
<cfoutput query="q">
<cfset b = q.id eq arguments.id>
<cfset arrayAppend(aDebug, "currentRow: #currentRow#.
#q.id# eq
#arguments.id# = #b#")>
<cfset arrayAppend(aDebug, "THIS SHOULD WORK TOO (but
doesn't))!
currentRow: #currentRow#. #q.id# eq #arguments.id# = #q.id eq
arguments.id#")>
<cfif q.id eq arguments.id>
<cfset arrayAppend(aDebug, "I am about to
return out of this
method")>
<cfreturn currentRow>
<cfset arrayAppend(aDebug, "This is after the
CFRETURN, but I
never get hit")>
</cfif>
</cfoutput>
<cfset arrayAppend(aDebug, "Oops... I am still IN this
method?!?!")>
<cfdump var="#aDebug#">
<cfabort>
</cffunction>
</cfcomponent>
<!--- returnInQueryLoop.cfm --->
<cfset o = createObject("component", "ReturnInQueryLoop")>
<cfoutput>#o.f(id=2)#</cfoutput>
If you look at this, you will see that there's no real way one should
end up outside the bottom of the <cfoutput> block. The return
statement should trigger on the second row of the query, because 2
does indeed equal 2. Indeed the <cfreturn> statement *does* trigger,
but all it does is the equivalent of a <cfcontinue>: skipping to the
next iteration of the loop. It doesn't actually return!!
CF8 performs exactly as one would expect here (ie: 2 gets output on
the screen, and that's it).
So that's not a great one.
And the second bug is with this line:
<cfset arrayAppend(aDebug, "THIS SHOULD WORK TOO (but doesn't))!
currentRow: #currentRow#. #q.id# eq #arguments.id# = #q.id eq
arguments.id#")>
What that appends to the array is the word "no". This has something
to do with this expression:
#q.id eq arguments.id#
Because if I remove it, I then get the string appended to the array as
one might expect.
Again, no such issue on CF8.
Please note: this is not some weirdo contrived case I have
concocted... the original code was within MXUnit... I've just
refactored it into a simple repro case as part of working out WTF was
going on (needless to say, it took a bit of guessing, because I really
really didn't expect <cfreturn> to not work properly!!
Fortunately this is only biting me on the bum in a unit test I had
written to test a bug in MXUnit itself (you guys are not the only ones
I harangue with bugs, trust me... MXUnit, MockBox and Adobe all get it
too. Oh boy do Adobe get it ;-). I've finished testing MXUnit, so I
can remove the test now and crack on with my other tests. However at
least the first one is not an insignifcant bug, so it'd be really good
if you could look at it. The second one is a curio more than anything
else. And it was funny (to me... my sense of "humour" is weird) that
I found a bug whilst trying to troubleshoot another bug...
Right.
I'm off to install Railo and rerun my unit tests and see what grief I
get with that.
Cheers.
--
Adam
--
Open BlueDragon Public Mailing List
http://www.openbluedragon.org/ http://twitter.com/OpenBlueDragon
online manual: http://www.openbluedragon.org/manual/
mailing list - http://groups.google.com/group/openbd?hl=en
