Just to note (I don't have the examples handy here), cfoutput w/ loop in CF7/8 has it's own oddities as well.
Not to downplay any bug you are seeing here, but I'd not output from a function directly. So Adam's suggestion of using cfloop is a good idea. As for openbd not being production ready, I'll take issue with that. I and the entire team Mach-II have spent years making Mach-II compat with all the cfml engines. To be honest, each engine has it's own "weird" bugs. To cast out openbd due to a single bug is less than pragmatic. It's throwing the baby out with the bath water ;-) We've found that OpenBD and Railo are able to fix bugs in just days or weeks whereas I'm still waiting for bugs / oddities from CF6/7 days to be fixed (years). The turn around time is starkly different. Really, it's an impossible task to find all of the differences in implementations with the engines. It's people (like you) that spend time to find and *report* them that makes projects like OpenBD and Railo a great community and a great place to collaborate. So I hope you continue to do so. As a side note, developing apps for all the engines is a learning process and in the end it is a lowest common denominator situation. Just based on my experience, CF is the least strict on things and Railo/OpenBD are the most strict. No saying that strict is better, but being more loose about stuff just means you have more rope to hang yourself with usually. Off the top of my head based on the Mach-II code based, I'd say each engine equally has the same amount of bugs. .Pjf -----Original Message----- From: Adam Cameron <[email protected]> Sender: [email protected] Date: Thu, 22 Jul 2010 14:57:59 To: Open BlueDragon<[email protected]> Reply-To: [email protected] Subject: [OpenBD] Re: Two bug for the price of one Just a note: using <cfloop> works fine. It's just <cfoutput> that's bung. That might narrow-down the search for the bungness..? -- Adam On Jul 22, 7:53 pm, Adam Cameron <[email protected]> wrote: > 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 -- 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
